Azure app service windows container - Uploading file to File share using mount storage error

Question

I have an simple .NET 4.5 mvc app, which performs simple file upload to a directory.

This app has been containerized to windows container and deployed on Azure app service webapp as containers.

It has option to mount Azure files storage as persistent storage volume to the container.

So I have mapped the mount to point the upload directory. The idea is when user upload the file, it will go to Azure Filestorage via the mount volume.

The mount is successful, how ever when trying to upload getting error "The Parameter is Incorrect" from system.IO.

If we inspect the Azure Filestorage from the storage explorer, there is been an empty file being created. Not sure what is going wrong.

2020-10-17 02:36:20,959 82924433ms INFO  FileHelper             UpLoadFile             - ToFilePath : C:\inetpub\wwwroot\FileStorage\UserProfileImages\banner-img.jpg
2020-10-17 02:36:20,975 82924449ms ERROR FileHelper             UpLoadFile             - Error in saving file. The parameter is incorrect.

2020-10-17 02:36:20,975 82924449ms ERROR FileHelper             UpLoadFile             - System.IO.IOException: The parameter is incorrect.

   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
   at System.IO.FileStream..ctor(String path, FileMode mode)
   at System.Web.HttpPostedFile.SaveAs(String filename)
   at ConnecTiQa.Mvc.Helpers.FileHelper.UpLoadFile(HttpPostedFileBase file, HttpServerUtilityBase server, String rename, String SaveFilePath) in C:\app\ConnecTiQa.Mvc\Helpers\FileHelper.cs:line 204

Storage account screenshot

Update 1:

Not only update. Having issue with accessing the file(reading) from the mounted volume as well.

Mount volume file access error

Answer 1

The problem is that the mount in the Windows container only has the permission RX, see the screenshot here: You do not have the write permission in the mount point, so you cannot write the content into the files.

Update:

I made a mistake and I'm sorry about that. The mount point is the path that you set in the path mappings. For example, if you set the mount path as /inetpub/wwwroot/filestorage/mnt, then the mount point is the final folder mnt, and all the actions in it would be incorrect:

I'm not sure if this the issue, but I guess it's the problem.

Answer 2

This was too long to post as a comment. Direct from Microsoft Support:

Hypervisor-isolated containers run inside a lightweight component called a UVM (Utility VM). When a directory from the host is mapped into a hypervisor-isolated Windows container, Hyper-V uses VSMB (virtual SMB) to map the share into the UVM. VSMB supports an optimization called direct map, which reduces memory overhead on the host for the share. As part of supporting direct map, VSMB must be able to query for the file ID of the file being accessed. So in this case VSMB would be querying Azure Files to get the file ID. However, Azure Files currently does not support querying for file ID from its shares, and this is what produces the ERROR_INVALID_PARAMETER error that is observed when accessing the share.

There are effectively two issues here: Azure Files does not support querying for file ID. I have started a thread with a contact on Azure Files to see if this is something they could support in the future. When querying for file ID fails, VSMB does not fall back to using a non-direct mapped access to the share This bug exists in 19H1, 20H1, and 20H2. In RS5 VSMB did not query for file ID, but this was changed in 19H1 to make VSMB more correct, and eliminate other bugs. Post-20H2, this bug has been fixed so that VSMB will fall back to non-direct map if the file ID query fails, but there hasn't been a new version of Windows Server since the bug was fixed. The fix will be available in the next Windows Server release.

But still we have the issue with azure file that does not support querying for file ID and there is no ETA at this point. The Windows team is looking at it in this case a workaround recommended by our product group is to use another mechanism like the Azure SDK for .NET for reading/writing files to storage