This project has moved and is read-only. For the latest updates, please go here.

store VeraCrypt container on NAS and access non-simultaneously by different systems?

Topics: Technical Issues
Feb 16, 2015 at 3:54 AM
I understand the limitations about simultaneous access of a VeraCrypt (or TrueCrypt) container that's stored on a network share. But I'd simply like to be able to mount the same container on two different computers independently, never at the same time. This was working just fine for a day, where I'd make sure to dismount the container on one machine before mounting it on another. However, suddenly I was met with an error when attempting to mount it on my Macbook:
hdiutil: attach failed - no mountable file systems
Is there some sort of lock that is preventing it from being mounted as a writeable image? I can only mount it as read only now, despite the steps I've taken to ensure dismounting it before mounting it on another machine. I'm confused why this would create a problem, and if it's possible to update VeraCrypt to overcome this limitation. It'd be great if there was a mechanism in place to prevent simultaneously mounting the same container as writable, but allow any machine to grab write permission when the container is currently not mounted by any other machine. Thanks.
Feb 22, 2015 at 2:54 PM

Sorry of the late answer, other issues popped up in between.

There is no lock mechanism in VeraCrypt to protect again mutual access of volumes. VeraCrypt open a file descritor on the container for read/write access and it is the responsibility of the operating system to transfer any read/write calls to the NAS. From the point of view of VeraCrypt, a local file or a file on a NAS are handled the same because we use the operating system file I/O API to access them and this API ensures that they are handled the same way.

I can find any explanation for the issue you are encountering other than it has something to do with your netword share handling. As far as VeraCrypt is concerned, low level file handling is delegated to the operating system.

Implementing some sort of proprietary mechanism to handling locking of shared resources requires the use of an extra file on the shared location that will hold information about all clients accessing the file container. This is the only solution since we are not running the server ourselves.
By experience, handling this kind of lock files can be a night mare for network shared and they are also "leak" information about the users of the sensitive resources which is something that we don't want to have.
For these reasons, no such lock mechanism will be implemented and VeraCrypt will remain focused on encryption, leaving it to the user to handle complex usage scenario which are difficult to handle in a generic way.
For the record, there is a chapter on the documentation that deals with sharing containers over the network: