Mount Blob storage on Linux VM NFS 3.0
Published Feb 11 2021 05:08 AM 4,945 Views

Hello Folks!


Not so long ago I was working on an internal project that required me to deploy Linux VMs that were hosting a workload that saved a copy of any number of video live feeds to blob storage for safeguard and for future replays.  I also needed it to be mounted automatically when the VM was created.


I know that are several ways to map storage in a VM. You can:


  1. How to mount an NFS file share
  2. Use Azure Files with Linux over SMB
  3. How to mount Blob storage as a file system with blobfuse
  4. Mount Blob storage by using the Network File System (NFS) 3.0 protocol (preview)

I decided to give the NFS path a try.


Why NFS you may ask?


I'm not sure... Could be because NFSv3 provides compatibility for existing applications, could be because of the scale it can support or maybe just because it's cost effective and easy to setup.

In any case, I followed the documentation here  to create the virtual network, service endpoint to ensure that the storage account can only be accessed from the appropriate vnet and subnet, and the storage account.


To automate this at the time of deployment I added the following few lines to the Custom Script Extention script i use to deploy the workload on a new VM at deployment time.






apt update
apt install nfs-common -y
mkdir -p /mnt/livefeed
mount -o sec=sys,vers=3,nolock,proto=tcp <storage-account-name><storage-account-name>/<container-name> /mnt/livefeed






This worked great!


Except that the workload on the VM could not write to the blob storage. I realized that when the custom Script extension creates the folder livefeed in /mnt it's done by the Azure Agent user context (Root) and therefore the permissions on that folder




Only provide read write to Root. For my test I added the following line to the end of my script, and it worked like a charme.






chmod 777 /mnt/livefeed







I do Not promote giving all rights to all users in a production environment.



My next step is to create a group that include the user context which the workload in running under and change the permissions so only the account needed have write access.


I really believe in the Least-Privilege Administrative Models when it comes to any environments (On-Prem, Hybrid and cloud native).


In any case, I hope this may give you some ideas on how you can leverage Azure services to address problems in your environment.






Version history
Last update:
‎Feb 11 2021 05:08 AM
Updated by: