> ## Content Index
> Fetch the complete content index at: https://jesscoburn.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Permanently Mounting Azure File Shares in Windows VMs: A System-Level Approach
- URL: https://jesscoburn.com/blog/permanently-mounting-an-azure-file-share-in-a-windows-vm/
- Published: 2018-06-27T16:55:56.000Z
- Updated: 2026-03-13T17:26:04.000Z
- Description: A technical workaround for mounting Azure File shares at the Windows system level to ensure persistent access across reboots and users.
- Author: Jess Coburn
- Tags: Azure

## The Challenge: System-Wide Azure File Share Access

Azure Files provides cloud-based file shares accessible to both Azure-hosted and internet-connected resources. However, a common operational challenge emerges when you need persistent file share access that survives server reboots and remains available to all users and services — without requiring individual user authentication each time.

This guide addresses mounting Azure File shares at the system level, ensuring enterprise-grade accessibility and persistence.

## Prerequisites

Before implementing this solution, ensure you have:

- **Azure Storage Account**: Pre-configured with your file share (path format: ACCOUNTNAME.file.core.windows.net/SHAREDFOLDER)
- **Storage Access Key**: Located in your storage account's "Access Keys" section
- **PsExec Tool**: From the Microsoft Sysinternals Suite for system-level command execution

## Implementation Steps

### Step 1: Establish System-Level Access

Open an administrator command prompt and execute:

```
psexec -i -s cmd.exe
```

Verify system-level access by running:

```
whoami
```

This should return "nt authority\\system".

### Step 2: Store Credentials Securely

Add the storage account credentials to the system credential store:

```
cmdkey /add:ACCOUNTNAME.file.core.windows.net /user:ACCOUNTNAME /pass:MYKEY==
```

### Step 3: Mount the File Share

Create the persistent network drive mapping:

```
net use M: \\ACCOUNTNAME.file.core.windows.net\SHAREDFOLDER /u:ACCOUNTNAME MYKEY== /persistent:yes
```

**Note:** The drive may appear as "disconnected" in Explorer but will function correctly for system operations.

### Step 4: Configure Automatic Remounting

To ensure the share remounts after system reboots:

1. Open Local Group Policy Editor (gpedit.msc)
2. Navigate to Computer Configuration → Windows Settings → Scripts → Startup
3. Create a batch file containing only the net use command from Step 3
4. Add this batch file to the startup scripts

## Verification and Management

After reboot, the M: drive should be available to all users and services. To remove the mapping later, use the same PsExec system-level approach with:

```
net use M: /delete
```

## Important Considerations

**This approach represents a workaround rather than a supported Microsoft solution.** While functional, consider these factors:

- Not officially supported by Microsoft Azure
- Requires careful testing in your specific environment
- Should be documented as technical debt for future modernization
- Consider Azure File Sync or other officially supported alternatives for production environments

## Strategic Takeaway

While this system-level mounting technique addresses immediate operational needs, modern Azure architectures should prioritize officially supported integration methods. As Azure services evolve, evaluate whether newer solutions like Azure File Sync, Azure NetApp Files, or container-based storage approaches better align with your enterprise architecture strategy.

This approach remains valuable for legacy systems and specific use cases where standard user-level mounting doesn't meet operational requirements.