When creating an Azure function with an Dedicated (Standard) App Service Plan the file service I'm expecting to get "linked" up isn't getting "linked" to the storage account. However the Storage account does get created correctly. When I go to the Azure Storage Accounts blade and find the file storage, Azure doesn't have the file service linked to the Storage Account. I don't see any linked File Shares when using the Windows desktop software, Microsoft Azure Storage Explorer (0.9.6).
When I go to the Azure Function's Advanced Tools (Kudo) I can see the storage account folders "Data", "LogFiles", and "Site" with the wwwroot I'm expecting to find. However due to certain network restrictions I can't upload the code through the web-site so that option is out.
When creating a Consumption based plan everything links up nicely and I can manage them in the Azure Storage Explorer app. How can I get my already created File Service File Share linked to my already created Azure Function so I can manage it in the desktop app and get things appearing correctly linked up in the Storage Explorer?
There's a solution for you to refer, as it works on my side. In portal, Application Settings Tab, add two application settings below:
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING storage account connectionstringWEBSITE_CONTENTSHARE file share nameAnd some explanations for you.
When creating a function app, the storage account we specified is mainly used to store logs and files like host locks. Only for function app created in consumption plan, it automatically adds the two application settings above and uses File Share to store whole function app by default.
As Azure document says, the File Share related settings is for consumption plan only. It seems not an expected operation for function created in app service plan, but it works in practice anyway.
Update
For a function app created in app service plan, assume its files are stored in place A(somewhere on the server). It works well and kudu displays files stored in A. So far it has nothing to do with file share.
Then we add the two settings, and assume the file share is B. System retains old files(if exist) in B and creates an empty function app in it. From now on, system targets at and leverage files in B, as long as the "link"(two settings) exist. In portal, kudu or app service editor, we see files in B and also changes will be saved there.
And if we delete the "link", everything returns to A. Need to wait a little while for system "redirecting".
All explanation is based on my test(dozens of times) since it's an unexpected operation and has no document description.