IIS, NFS, and the Drive Letter Trap: Using OCI File Storage on Windows for High Availability (HA)

Recently, I came across an interesting problem while working on a customer deployment on Oracle Cloud Infrastructure (OCI).
This post is a technical field note for myself and people who might find themselves in a similar situation.Definetly not a reference architecture or a best-practice guide. It documents:

• A real life issue encountered when running IIS on Windows with OCI File Storage Service (FSS)
• The thought process behind the initial design
• What failed, and why it failed
• The minimal change required to make it work

I thought it was just a practical issue that can easily show up when moving Windows workloads from on-premises to OCI, and decided to write about it.

1 The use case
Customer has an ASP.NET application running on IIS, previously deployed on-premises. And they are in the process of moving the application to Oracle Cloud Infrastructure, with the following design:

• Two IIS nodes (Windows Server 2022 Standard)
• High availability deployment
• All application servers in a private subnet
• A public load balancer in front

So far, this is a fairly standard 2/3-tier web deployment.

The complication
The application stores some data on disk, and that data is meaningful only when combined with database records (for example: uploads, generated files, artifacts, etc.).

Once you go multi-node, the obvious question appears: How do both web servers see the same files? A shared storage layer is required.

2 First approach: shared storage with OCI FSS
The natural choice here was OCI File Storage Service (FSS):

• Managed NFS service
• Simple to mount on multiple instances
• Works well for shared file access across compute nodes
• Many features for resillience (backup/restore, snapshot, cross-region replication, etc.)

The plan was straightforward:

• Create an FSS export and mount target in private subnet
• Mount File Systems on both Windows IIS instances
• Point the application to a shared directory

Where things start to break
The FSS export was mounted successfully on both Windows servers:

• The NFS client was installed
• The mount was visible at the OS level
• Files could be created manually from command line and explorer, and it was visible on the other node.

However, the application had a fixed directory structure and expected a specific path under wwwroot. So when I decided to add a Virtual Directory another surprise appeared: IIS doesn’t even “see” the NFS-mounted drive. How could the application use it?

The symbolic link idea
The first workaround that came to mind was simple: Create a symbolic link under C:\inetpub\wwwroot that points to the NFS mount.

This approach often works with local disks and SMB shares, so it looked reasonable. However, once the application was tested, file operations failed with the following error: Error: Could not find a part of the path 'C:\inetpub\wwwroot\FSSApp\data\test.txt' At this point:

• The path did exist
• The symbolic link was valid
• The same path worked from an interactive PowerShell session
• The failure happened only when accessed from IIS

So the question became: What exactly is going on here?

3 What’s actually going on between IIS and NFS
Initially, this looked like an identity or authentication problem, but further testing showed that the real issue was more fundamental.

Drive letters and Windows services
On Windows, drive letters are session-scoped.

This means, a drive letter is associated with the user session that created it. It is visible to that user in Explorer and PowerShell. It is not automatically visible to Windows services. You will experience the same error when you launch command prompt as Administrator.

IIS worker processes run as services, execute in Session 0 and do not inherit drive mappings from interactive logons.

So when the NFS export was mounted using a drive letter (for example X:), the mount worked for the logged-in user. The symbolic link resolved correctly in PowerShell. However IIS could not resolve the same path. From IIS’ point of view, the target simply did not exist.

That’s why the application failed with "Could not find a part of the path" misleading but understandable. The path exists, but not in the IIS execution context.

Why the symbolic link didn’t work (at first)
The symbolic link itself was not the problem. From IIS’ point of view, the symbolic link resolves to "a drive letter that doesn't exist". Letter was assigned in an interactive user session.

Why UNC paths work
UNC paths are global, session-independent, resolvable by Windows services, accessible from IIS worker processes

When the symbolic link was recreated to point directly to the UNC path, application pool identity remained unchanged, pass-through authentication was still used and yet, file uploads worked immediately.

Root Cause
So the real root cause was not IIS vs NFS, and not strictly authentication. IIS cannot access drive-letter–based network mounts, because drive letters are session-scoped and assigned letter stayed in user session.

Where domains still matter
Active Directory and domain membership are not required for this specific fix. However, they become relevant when you need non-anonymous NFS access.

Even though IIS doesn't see session scoped mapped drive, the simplest and practical solution was using a symbolic link with UNC path and avoid drive letter. This way IIS directly can access to globally resolvable paths.

• Fix A: UNC path (simple, works immediately)
• Fix B: Domain-based identity (advanced / production)

4 The Working Setup
We install:

• IIS Web Server
• ASP.NET (my test application uses Web Forms)
• Required IIS dependencies

• NFS Client (Services for NFS)

• Mount FSS to X: drive (Command Prompt, not Power Shell)

• IIS can't see FSS

• Create symbolic link (Workaround)

• Create a test application, web form to upload file to data folder which is mapped to FSS

• Upload fails when symbolic link is created using session scoped Drive X:/

• Upload is successfull when symbolic link is created using UNC path to FSS