I am trying to share a single disk across multiple VM's (Ubuntu 18). The VM's are hosted in Azure and the disk is an Azure Managed Disk. I've attached the disk to both VM's and have mounted them. I can see the partition on each, as well as the test file I've created, test.txt. However, updates to the contents of the txt file while SSH'ed into VM1 are not reflected in VM22. Instead, the VM2 shows the prior value until I unmount and remount the drive.

I'm new to Ubuntu/Linux, and am trying to figure out where to look. My initial thoughts...

  • Perhaps the filesystem I'm using (gpt) cannot support multiple, concurrent access in this manner and I must use something else? If so, what is more suitable?
  • The VM seems to take a copy of the file when it's mounted and writes are not shared.
  • Perhaps this is the problem and this can be turned off?
  • Perhaps this is a problem with Azure, although I no longer believe it to be.
  • Perhaps there is a permissions issue because the user accounts differ between machines. I know Linux includes permissions on a file + directory basis as a first-class concern.

Any other thoughts?

2 Answers 2


Shared managed disks need to be used in conjunction with a cluster manager or similar to handle the concurrancy, the Azure feature is really just about being able to technically attach it to more than one VM. See the docs here:

Shared managed disks don't natively offer a fully managed file system that can be accessed using SMB/NFS. You need to use a cluster manager, like Windows Server Failover Cluster (WSFC), or Pacemaker, that handles cluster node communication and write locking.

As Tero mentioned, what you have done is a recipie for data loss.


GPT is a partitioning mechanism, not a filesystem.

Most filesystems are designed so that they assume exclusive access to the underlying block device. For example caching relies on the fact that all operations are seen by cache layer.

Your setup violates that assumption and that's why you see behavior like that. You have been lucky to have seen only such small problems. Data loss is guaranteed in any larger operations, as the filesystem metadata is updated by either party at their own time.

Now, the correct solution depends on your exact requirements.

Do you really need shared access on block device level?

If yes, then you need to use a clustered file system.

Or do you only need both servers able to access same set of files?

In that case, you should set up NFS server on one server, and NFS client on second one.

  • Writes will come from a different server in the future and these two will simply need read access. I guess I’m wondering what the point of a shared managed disk is then.
    – B P
    Oct 20, 2022 at 4:33
  • Why wouldn't something like NFS work in that scenario?
    – vidarlo
    Oct 20, 2022 at 14:15
  • There are use cases where sharing block device is required, like failover servers. The preference should still be a networked file system or even application level data distribution. When the distribution mechanism is made on higher levels, it is easier to guarantee its correctness. Oct 20, 2022 at 14:49
  • @TeroKilkanen @vidarlo i'm looking to monitor a directory for changes from multiple VM's. anytime a file changes, each VM would run a script. i've been doing a poc with iwatch but my testing with NFS shows the watch is not picking up when changes occur. i can think of some other ways of doing this, but this seemed more intuitive.
    – B P
    Oct 20, 2022 at 21:00
  • 1
    I would use lsyncd for this purpose. I would set it up to monitor file, and then it could execute the script remotely whenever there is a file change. This requires some programming in Lua though. You could use any other watch mechanism that can execute a command. Then you just use ssh user@vm /path/to/script to run the script. Oct 20, 2022 at 21:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .