Azure-docs: persistent mount still doesn't work for linux dsvm

[rbavery]

when I restart the vm, the mounting takes effect, which I know because I can see the files in my file share. but when I deallocate the VM, my directory I created in the mnt folder is gone and I have nothing mounted. Is there a way to keep the mount persistent after deallocating and starting the vm? My smbcredentials are still there so I'm not sure why the directory I had created in /mnt would disappear.

This is the issue I referenced last time: https://github.com/MicrosoftDocs/azure-docs/issues/30571

To reproduce, start a linux data science vm, have a fileshare with files, and copy paste the persistent mounting string for the azure file share into your VM's shell. Run and then restart the VM, verify that it is mounted, and then deallocate and start the VM againa nd see that your mount point is now gone.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 8d60d83f-0094-6c5e-e105-712c24bf1acc
• Version Independent ID: 594af294-fd5d-a8c7-d456-6d753b7b62f8
• Content: Use Azure Files with Linux
• Content Source: articles/storage/files/storage-how-to-use-files-linux.md
• Service: storage
• Sub-service: files
• GitHub Login: @roygara
• Microsoft Alias: rogarana

[rbavery]

also, I found an error in the connection script that is supplied. The mkdir command uses the name of the storage account rather than the name of the fileshare for the mount directory of the vm. the last command that does the mounting uses the file share name.

[rbavery]

It looks like after deallocating I can remount my fileshare with the following two commands. Good enough! I think it'd be useful to have the docs updated to reflect this quirk. and if there is any adjustment that is made to the persistent mounting script so that these commands don't need to be run I'd be interested to hear about it.

ryan@cropmask-dev:~$ sudo mkdir <moint-point>
ryan@cropmask-dev:~$ sudo mount -a

[SumanthMarigowda-MSFT]

@rbavery Thanks for bringing this to our attention. Your feedback has been shared with the content owner for further review.

[timlod]

Hi,
I had the same problem and fixed it by adding x-systemd.automount to the fstab line options.
This will make it wait for the network to be online before mounting the share.
Edit:
Apparently this does not work without fail.
When I restarted my VM it mounted the share, but when reallocating the VM it did not mount it.
So this issue is not solved.

[marinnedea]

@timlod and @rbavery - please check https://blogs.msdn.microsoft.com/mast/2013/12/06/understanding-the-temporary-drive-on-windows-azure-virtual-machines/

I think you are using the /mnt mountpoint, which by default in Azure Linux VMs is designed to hold the temporary disk (on some distributions the path is /mnt/resources ).

Because of this, on redeploy, you'll lose the directories created under /mnt .. because you actually created them inside a temporary disk, that, on re-deploy, will be removed and re-created.

P.S. You can change that temporary disk mountpoint in /etc/waagent.conf:

Provisioning.UseCloudInit=n
ResourceDisk.Format=y
ResourceDisk.MountPoint=/path/to/your/new/mount/point

Make sure the /path/to/your/new/mount/point exists.

[timlod]

Hi @marinnedea, thanks for the reply!

Why does all the documentation for Azure Linux VM file share mounting have /mnt as the default path, also for persistent mounting, if that will, using default configurations, never work?
E.g. https://docs.microsoft.com/en-us/azure/virtual-machines/linux/mount-azure-file-storage-on-linux-using-smb
Also, I'm using the Azure Data Science Virtual Machine. It does not use ResourceDisk.Format=y.
Hence my directories are not deleted on re-deployment. It just does not mount the file share.
But perhaps the mounting issues happen because I'm mounting a file share on another mounted disk.
I will investigate this further.

[rbavery]

Thanks @marinnedea . What's the recommended mount point for fully persistent mounting? Or is it your recommendation to change the path to the temporary mountpoint to some other directory I create beforehand?

[marinnedea]

@timlod - I think the one creating the documentation used the legacy mountpoint /mnt as an example, without taking into account the temporary disk. Not sure if this was because they weren't aware of the temporary disk or for some other reason.. but /mnt or /mnt/resources (depending on the Linux distro) should be avoided.

@rbavery - you have 2 options here:

1. Change the mountpoint of the temporary disk by modifying the /etc/waagent.conf
2. Use a different custom mountpoint for your disks, e.g. create a /datadisks directory, and use that one.

My personal preference is to use the 2nd option, simply because I don't like playing around with the /etc/waagent.conf, unless absolutely necessary.

[roygara]

@rbavery thanks for reaching out, we appreciate it!

As @marinnedea pointed out (thank you as well, by the way! :D ) this is probably happening because it is mounting to the temp disk. The documentation is currently out of date and we're working to create an up to date version now. We're also working on new guidance right now, actually.

For now, you could use something like //.file.core.windows.net/ as a new mount point, or really anything that's not mounted in the temp disk.

[rbavery]

Ok cool thanks for your help both of you!

[JoeBerg8]

this is an incredibly useful thread. thank you guys

[roygara]

@rbavery We've updated the article with new instructions and cmdlets. Although so far just this article, there may still be out of date cmdlets in the rest of the docset. We're working on that and are tracking it separately.

Thanks again for bringing this up. :)

please-close

[gdippolito]

This is very inconsistent with your own documentation and common established practices: