Mount Configuration¶

Mounts let you map directories from your host machine (or network) into the SAS container, so SAS programs can read and write files without copying data into the container.

Method	Use Case
Auto-mount	Quick access to all fixed drives
Local directory	Mount a specific folder from your machine
Network share	Mount a CIFS/SMB network share

Mount configuration is available in the Mounts tab of the desktop form after the first save.

Local Directory Mounts¶

Adding a Local Mount¶

Click Add Mount in the Mount Configuration section
Select Local Directory as the mount type
Enter the Source Path — absolute path on your host (e.g. /Users/yourname/sas-data)
Enter the Target Path — where it appears inside the container (e.g. /data)
Choose Access Mode — Read-Write or Read-Only
Click Add Mount

Path Validation¶

Paths are validated as you type:

Source path must be an absolute path on your host machine
Target path must be an absolute Linux path (starts with /)
Target paths cannot conflict with reserved container paths (/opt/sas, /sasinside, /proc, /sys, /dev)
Duplicate or overlapping target paths are blocked

Sensitive directories

Security warnings appear when mounting directories like ~/.ssh, ~/.aws, or system directories. Consider mounting only the specific subdirectory you need.

Docker Desktop file sharing

Docker Desktop only shares certain host directories with containers by default (/Users on macOS, C:\Users on Windows, /home on Linux). If your source path is outside these locations, you must add it to Docker Desktop's file sharing settings: Settings → Resources → File sharing. The extension will display a warning if this may be required.

Example¶

Field	Value
Type	Local Directory
Source Path	`/Users/yourname/projects/analytics/data`
Target Path	`/data`
Access Mode	Read-Write

In SAS:

libname mydata "/data";

Mount CIFS/SMB file servers into SAS containers. The extension creates Docker volumes with the CIFS driver automatically.

Supported File Server Types¶

File Server Type	Supported	Per-User Identity Preserved	Credential Configuration
Windows file server (domain-joined)	✅	✅	AD username + password + domain
Azure Files (storage account key)	✅	❌	Storage account name + access key
Azure Files (Entra ID / user identity)	❌	N/A	Not supported — see below
On-premises NAS (SMB)	✅	Depends on NAS	NAS username + password

Per-user file permissions

If your organisation requires that each user can only access files they are individually permitted to view or modify, you must use a traditional Windows file server (domain-joined to Active Directory). Azure Files does not support per-user identity when accessed from Docker containers.

Windows File Server (Recommended for Per-User Security)¶

When connecting to a traditional Windows file server that is joined to Active Directory, each user's identity is preserved. Files created from within the SAS container are owned by the authenticated AD user, and NTFS permissions are enforced server-side.

Credential profile configuration:

Field	Value	Example
Profile Name	A friendly name	`Corporate File Server`
Username	Your AD username (without domain prefix)	`jsmith`
Password	Your AD password
Domain	Your Active Directory domain	`CORP`

Mount configuration:

Field	Value	Example
Source Path	UNC path to the share	`//fileserver.corp.local/shared-data`
Target Path	Path inside the container	`/data`

Azure Files (Storage Account Key)¶

Azure Files shares can be mounted using a storage account access key. This provides access to the share but all operations are performed as a single identity (the storage account) — per-user NTFS permissions are not enforced.

Credential profile configuration:

Field	Value	Example
Profile Name	A friendly name	`Azure Storage - Analytics`
Username	The storage account name	`mystorageaccount`
Password	A storage account access key	(from Azure Portal → Storage Account → Access Keys)
Domain	Leave blank

Do not enter your Azure / Entra ID credentials

Azure Files does not accept personal user credentials (e.g. user@company.com) for SMB mounts from Docker containers. You must use the storage account name as the username and a storage account access key as the password. Contact your Azure administrator if you do not have access to the storage account keys.

Mount configuration:

Field	Value	Example
Source Path	UNC path to the Azure file share	`//mystorageaccount.file.core.windows.net/myshare`
Target Path	Path inside the container	`/data`

Finding your Azure Files connection details

In the Azure Portal, navigate to your Storage Account → File shares → select your share → Connect. The connection panel shows the storage account name, access key, and UNC path.

Azure Files — Unsupported Scenarios¶

The following configurations do not work and will result in "permission denied" errors:

Using your personal Entra ID (Azure AD) email and password as credentials
Using your Windows login credentials (AZUREAD\username)
Attempting to use the same credentials that map the drive on your Windows PC

This is a platform limitation: Azure Files requires Kerberos authentication for per-user identity, and Docker Desktop's Linux kernel does not support Kerberos-authenticated SMB mounts.

If your Azure Files share enforces per-user NTFS permissions and you need those permissions honoured inside the SAS container, the share must be migrated to a traditional Windows file server joined to Active Directory.

Prerequisites¶

The network share must be accessible from your machine on port 445 (SMB)
Valid credentials for the share (see supported types above)
Share path in UNC format: //server/share
A credential profile must be created first

Creating a Credential Profile¶

Navigate to the Mounts tab in the desktop form
Click Credentials
Fill in the fields according to your file server type (see tables above)
Click Save

Passwords are encrypted with AES-256-GCM before storage and are never displayed in the UI.

Adding a Network Mount¶

Click Add Mount
Select Network Share
Enter the Source Path in UNC format (e.g. //fileserver/shared-data)
Enter the Target Path (e.g. /network/shared)
Choose Access Mode
Select the Credential Profile
Click Add Mount

Managing Mounts¶

Status Indicators¶

Status	Meaning
🟢 Active	Mount is enabled and will be used when the container starts
⚪ Disabled	Mount exists but won't be used until re-enabled
🔴 Error	Mount has a validation error — check the tooltip

Actions¶

Toggle — enable or disable a mount without deleting it
Edit — open the mount form with pre-filled values
Delete — permanently remove the mount (cannot be undone)

Docker Integration¶

When you start a desktop, enabled mounts are converted to Docker arguments:

Local mounts: --mount type=bind,source=/path,target=/data
Network mounts: --volume {cifs-volume-name}:/network/share

Mounts are validated before container startup:

Errors (path traversal, reserved paths) block startup
Warnings (sensitive directories) are logged but don't block
Source path existence is validated by Docker when the container starts