This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(144, 53%, 23%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESA%3C/text%3E%3C/svg%3E)
Facing issue when try to upload file to a mount path in windows container in azure app service. The mount path linked to Azure File Share.
I have tried creating 3 different application to test .net MVC, .net Core MVC and node js. In all attempts received same error "The Parameter is Incorrenct".
I have connected to the container via console and tried to create a sample file via command line. received same error.
But it creates an empty file in the Azure File Storage. Below is the storage explorer screen shot.
Have you checked the Microsoft reference here showing some solutions: storage-troubleshoot-windows-file-connection-problems
Yes. I have checked. My use case different, which is an container storage mount via app service web app as containers.
Please check if the ports requirements are met in the container instance. For example, I saw the port 443 is to be opened
@Singaravelan Alagumuthu Firstly, apologies for the delay in responding here and any inconvenience this issue may have caused. Based on the error message, Issue could be caused by port block 445
To check if your firewall or ISP is blocking port 445, use the AzFileDiagnostics tool or Test-NetConnection cmdlet.
Is this happening to specific files, can you try in different storage account and let us know the status.
The mount point is the path that you set in the path mappings. For example, if you set the mount path as /Users/sumarigo/Desktop/file storage/MBR, then the mount point is the final folder MBR, and all the actions in it would be incorrect.
Hope this helps! Kindly let us know if the above helps or you need further assistance on this issue.
Looking forward for your reply!
------------------------------------------------------------------------------------------------------------------------------------------
Please don’t forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(16, 66%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ER%3C/text%3E%3C/svg%3E)
@Sumarigo-MSFT which firewall are you talking about - are you talking about a setting on the Azure App Service resource?
What does ISP have to do with it when this is a resource hosted in Azure? (you've got an Azure web app app service mounting an Azure Files SMB file share)
How do you recommend the cmdlet be used i.e. should we use Kudu on the app service to go to a console, run powershell and then run the command Test-NetConnection ... are there any particular parameters in that command we are meant to use? What should we expect to see or not see in the output to know if port 445 is blocked?
This happens for all files (at least in my case which sounds the same) and happens in any storage account (I've set this up in multiple Azure subscriptions to test).
@Sumarigo-MSFT can you please explain this comment a bit more "The mount point is the path that you set in the path mappings. For example, if you set the mount path as /Users/sumarigo/Desktop/file storage/MBR, then the mount point is the final folder MBR, and all the actions in it would be incorrect." ... what are you saying is incorrect, and what would be a correct path? We tried using the Azure CLI https://learn.microsoft.com/en-us/azure/app-service/configure-connect-to-azure-storage?pivots=container-windows as well as the Azure portal to do the mounting and both still had issues. My understanding is that the mount-path simply corresponds with a folder on C: drive e.g. mount-path of /users/sumarigo would result in a folder being created c:\users\sumarigo ... which would show the contents of the fileshare you included in the share-name.
I got in contact with Microsoft and they said "This bug has been acknowledged by Product Group and they are currently working on it to resolve as soon as possible. However, there’s no ETA currently as to when the bug will be fixed.". I've asked for an issue/ticket reference so I can track when it is resolved but haven't heard back yet.
Thanks for the info @Rob
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(96, 71%, 19%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMT%3C/text%3E%3C/svg%3E)
Is this issue resolved by Microsoft for windows app service container ?? Not able to create files from kudu console of the Azure app service on the mounted path of azure fileshare
No, this issue isn't resolved yet. More info is here: https://stackoverflow.com/questions/64398512/azure-app-service-windows-container-uploading-file-to-file-share-using-mount-s/64916067#64916067 ... I have someone from Microsoft giving me updates (I no longer need this functionality for what I'm doing but I'm curious as to its eventual resolution)... I'll post back when they indicate they think it is fixed.
@MS Techie my understanding is that the problem should be fixed now. Engineers discovered that the issue was produced by a regression introduced in the Windows SAC 20H1 release used by Azure App Service to power Windows Containers. A private fix was rolled out to App Services at end of December 2020, and the private fix will be removed in a few months when a proper fix to Windows is released around the first quarter of 2021. I don't have a test environment to confirm it's working though.
To minimise such regression errors occurring again in the future they have done the following:
Overall it was disappointing how long it took to get this information from support, and it would have been good to have the issue documented in the Microsoft Learn.