Many Windows users and developers prefer mapping remote SMB/CIFS shares (e.g., from Linux/Samba servers) as directories rather than drive letters. The standard net use command assigns drive letters (e.g., Z:), but this approach has limitations:

• Drive letters are limited (A-Z)
• Directory mounts integrate better with workflows
• Scripts and applications often expect fixed paths

Windows supports mounting shares as directories via directory junctions. Here's how to implement it:

# First map the share temporarily with a drive letter
net use Z: \\Server\ShareName /persistent:no

# Create the target directory if needed
mkdir C:\Folder\ShareName

# Create the junction
mklink /J C:\Folder\ShareName Z:\

# Remove the temporary mapping
net use Z: /delete

For automated logins, store credentials securely:

# Store credentials (run as admin)
cmdkey /add:Server /user:username /pass:password

# Create a batch script for startup
@echo off
net use Z: \\Server\ShareName /persistent:no
mklink /J C:\Folder\ShareName Z:\
net use Z: /delete

While SUBST can map drives to paths, it has limitations with network shares:

# This won't work directly with UNC paths
subst X: C:\Folder\ShareName

For more control, use PowerShell scripts:

# PowerShell mount script
$share = "\\Server\ShareName"
$localPath = "C:\Folder\ShareName"

if (!(Test-Path $localPath)) {
    New-Item -ItemType Directory -Path $localPath
}

$tempDrive = "Z:"
net use $tempDrive $share /persistent:no
New-Item -ItemType Junction -Path $localPath -Value $tempDrive
net use $tempDrive /delete

• Requires administrative privileges
• Junctions work at filesystem level, not network level
• Some applications may not handle junctions properly
• Monitor for broken links if the share becomes unavailable

Create a scheduled task to run at login:

schtasks /create /tn "Mount Share as Directory" /tr "C:\path\to\script.bat" /sc onlogon /ru SYSTEM

When working with Windows clients accessing Linux/Samba shares, the standard net use Z: \\server\share approach creates drive letter mappings that can conflict with local storage and lacks filesystem integration. What we really want is seamless NTFS folder mounting like:

\\Server\ShareName → C:\Projects\TeamShare

The mklink command combined with authentication persistence provides the cleanest approach:

# First establish authenticated connection
net use * \\samba-server\devshare /persistent:yes /user:domain\username

# Create directory junction (requires admin)
mklink /D C:\Projects\TeamShare \\samba-server\devshare

For permanent mounts, use Disk Management with these steps:

1. Create empty folder at target location (e.g., C:\Mounts\Samba)
2. Open Disk Management → Action → Attach VHD
3. Enter UNC path: \\samba-server\share
4. Authenticate when prompted

For deployment scripts, this PowerShell function handles credentials and mounting:

function Mount-SmbFolder {
    param(
        [string]$LocalPath,
        [string]$UncPath,
        [pscredential]$Credential
    )
    
    if (-not (Test-Path $LocalPath)) {
        New-Item -ItemType Directory -Path $LocalPath | Out-Null
    }

    $cred = $Credential.GetNetworkCredential()
    net use $UncPath /user:$($cred.Domain)\$($cred.UserName) $cred.Password
    
    $null = cmd /c mklink /D $LocalPath $UncPath
}

# Usage:
$cred = Get-Credential
Mount-SmbFolder -LocalPath "C:\Dev\RemoteCode" -UncPath "\\samba01\repository" -Credential $cred

Key permission requirements for successful mounting:

• Local folder must have inheritance disabled
• Share permissions on Samba: valid users = @devteam
• NTFS permissions: chmod 2770 /samba/share (for sticky bit)