Why not use Azure File Shares for media folder?

Questions
1

Hi everyone,

We manage over 100 Umbraco websites, each running in its own Azure App Service, and we currently store the /media folders on Azure File Shares. These are mounted into the apps (e.g., /mounts/fileshare) and exposed as virtual directories (e.g., /media → /mounts/fileshare/media).

This setup is based on Microsoft’s official guidance for connecting App Services to Azure Storage, which recommends Azure File Shares for read/write access.

However, we’ve been experiencing frequent app restarts, and after investigation, we’ve confirmed they’re caused by File Change Notifications (FCN) triggered by the mounted media folders.

We’re now considering a move to Azure Blob Storage, as recommended in Umbraco’s official packages (Umbraco.StorageProviders.AzureBlob and AzureBlob.ImageSharp). But changing over 100 sites is a significant amount of work, so before we move forward:

  • Has anyone successfully resolved FCN issues while continuing to use Azure File Shares in App Services?
  • Are there any known mitigations, other than disabling FCN?

We’d really appreciate your input so we can weigh the options and make the most practical long-term decision. Thanks in advance for any insight you can share!

2

Hey Luis,

What version of Umbraco are you using?

I’ve never used Azure File Shares for this, and I’ve never come across an Azure Web App that does. Blob Storage is definitely the usual choice for this and will solve FCN problems - IF this is what’s causing them.

I question this as I’ve had FCN problems before, but never with media - IME media doesn’t change enough to cause these problems. I’m interested to understand how you came to the conclusion that it’s FCN + media changes specifically that’s causing the restates.

3

Hi Jason,

I’d prefer not to disclose the exact version here for security reasons, but happy to explain the setup more generally or discuss privately if needed.

All of our websites are experiencing a high number of recycles due to ConfigurationChange, with shutdown logs like this:

Application shutdown. Details: "ConfigurationChange"

Application shutdown. Details: “ConfigurationChange” _shutDownMessage=“CONFIG change HostingEnvironment initiated shutdown CONFIG change CONFIG change HostingEnvironment caused shutdown” _shutDownStack=" at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo) at System.Environment.get_StackTrace() at System.Web.Hosting.HostingEnvironment.InitiateShutdownInternal() at System.Web.Hosting.HostingEnvironment.InitiateShutdownWithoutDemand() at System.Web.HttpRuntime.ShutdownAppDomain(String stackTrace) at System.Web.Configuration.HttpConfigurationSystem.OnConfigurationChanged(Object sender, InternalConfigEventArgs e) at System.Configuration.Internal.InternalConfigRoot.OnConfigChanged(InternalConfigEventArgs e) at System.Configuration.BaseConfigurationRecord.OnStreamChanged(String streamname) at System.Web.Configuration.WebConfigurationHostFileChange.OnFileChanged(Object sender, FileChangeEvent e) at System.Web.DirectoryMonitor.FireNotifications() at System.Web.Util.WorkItem.CallCallbackWithAssert(WorkItemCallback callback) at System.Web.Util.WorkItem.OnQueueUserWorkItemCompletion(Object state) at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() at System.Threading.ThreadPoolWorkQueue.Dispatch() at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()"

In some cases, we’ve seen sites recycle over 20 times a day, often with multiple recycles in quick succession. A particularly critical issue occurs when the AppDomain is recycled just 18–20 seconds after claiming MainDom, which leaves Umbraco unresponsive and requires a manual App Service restart.

Our websites use SqlMainDomLock, and I suspect there’s an unresolved race condition that’s triggered by these closely timed recycles. I briefly reviewed the latest Umbraco version and it looks like this issue might still be present.

Here’s a diagram that outlines the race condition, based on a real incident where Umbraco was left unresponsive:

SqlMainDomLock Race Condition
SqlMainDomLock Race Condition789×1462 117 KB

Setting fcnMode="Disabled" immediately stops the ConfigurationChange-related recycles, which confirms that File Change Notifications (FCN) are the trigger. I then isolated the source: moving the /media folder back into wwwroot and removing the virtual directory (while using fcnMode="Single") eliminated the recycles entirely.

My working theory is that hidden metadata updates or background processes on the Azure File Share are being interpreted as file changes, which then trigger FCNs.

For reference, Shazwazza shared years ago that FCN and Virtual Directories (especially pointing to network shares) don’t mix well:

As it turns out, Virtual Directories in IIS are treated differently as well! The only FCN setting that affects Virtual Directories is “Disabled” (…) and as you can see, if it’s not disabled, it will be creating a directory watcher for every sub directory in the Virtual Directory. This problem is compounded if the Virtual Directory is pointing to a network share.

Thanks again for engaging with this — happy to go deeper on any part of the setup.

4

Given Shannon’s note, it looks like there’s no escaping from this then:

So if you are thinking of using “Single” and are using Virtual Directories, think again.

That said, I suspect this might be the case for ASP.NET on .NET Framework (Umbraco 8 and lower) but not necessarily for ASP.NET Core (Umbraco 9 and above).

Yes. There is a timeout setting that may help mitigate but this (also check DTU utilization) but the race condition was solved with the introduction of FileSystemMainDomLock, which is recommended for running on Azure (and is now the default).

So if you want to solve the FCN problem without upgrading Umbraco, then switching to Blob Storage is the way to go. But, I strongly recommend upgrading to a modern version of Umbraco.