Why does a mapped path in an Azure Web App from a blob container not work for virtual directories created with blobfuse?

Question

I have an Azure Web App with a mapped path from a blob container. The blob container is populated by mounting it to a directory in the filesystem of my local machine using blobfuse2. I created a folder ("test") and then added a text file to the folder. If I look at the blob container I see that there is the virtual directory and then at the same level another "marker" file with the same name that was created by blobfuse to support the hierarchical structure in a non-hierarchical Azure storage account.

The issue I am facing is that if I ssh to the web app I can't access the "test" folder. If I go to the mount point and run ls -la I see:

-rwxrwxrwx 1 kudu_ssh_user u244034a21a6cdf19473d34    0 Mar 22 15:29 test
-rwxrwxrwx 1 kudu_ssh_user u244034a21a6cdf19473d34    0 Mar 22 15:29 test

Neither of these is available as a directory and I cannot access anything that is inside the virtual folder "test" of the blob container. Why is this happening and how can I fix this?

Answer 1

@Derek Saffie Adding more information to the above response

By design FNS does not have a concept of a "folder". When you create a blob with path "A/B/c.txt" there are no folders "A" and "A/B" that exists in the backend, only a blob with name "A/B/c.txt" exists. But when this is viewed on the portal due to "/" being considered as a path seperator, portal shows "A" and "A/B" as directories. This is just visualization and not physical.

 Blobfuse is a file-system driver and using this user can create a new folder (which is empty in nature). FNS account does not support any such concept of empty folder and to overcome that Blobfuse creates a stub file (0 byte blob) with the folder name and has a special meta property set to identify it as a folder. This is an extra file with the same name and 0 byte in size is what you see while the actual folder displayed on the portal is just visualization and does not exists physically. Without the stub file blobfuse can not create directories in FNS.

Please let us know if you have any further queries. I’m happy to assist you further.    

---

Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

@Derek Saffie Thanks for posting your query on Microsoft Q&A.

When mounting a blob container using blobfuse2, ensure that you mount it with the appropriate permissions. By default, blobfuse2 mounts files with restrictive permissions (770), which means only the user who mounted the container can access them.

To allow other users (including the web app process) to access the mounted blob container, you can use the --allow-other option when mounting. This allows any user to access the BlobFuse2 mount. You can also configure this option in the YAML config file.

Please try the following troubleshooting steps and let me know the results:

• Verify that the blobfuse2 mount is correctly set up in your Azure Web App.
• Check the permissions on the mounted directory. Ensure that it allows read and execute permissions for the web app process.
• Confirm that the blobfuse2 process is running and properly mounted.
• If you’re using SSH to access the web app, make sure you’re using the correct user context (such as kudu_ssh_user). Instead of SSH, you can also try accessing the files through the Kudu console for your Azure Web App.
• Consider using the allow_other option when mounting the blob container to allow other users to access it.