Ideas for shaing files between 2 production environments

[The man with only 1 arm]

We are currently in the process of migrating away from a Windows production environment over to Linux.
As some of our production software will stay on Windows we working on a dual production environment(using VirtualBox 5.2.12), based on a Linux(Ubuntu 18.04 LTS) host with a Windows 7 guest.
One of my problems is sharing of data between the 2 environments and this is what I would ask help with.

Requirements

1. Laptops
   The system must work on laptops that change network settings(like wired or wireless).
2. Dual access
   Both production systems must have access to the same files. But not the same file at the same time.
3. Must work offline
   The solution must work without have access to a network. (Internal is okay, but not preferable).
4. No NAT
   The solution should work without using the Network NAT feature in VirtualBox.
5. Security
   The solution should not "break" normal security measures, like disabling UAC in windows or give the VirtualBox user root powers.

These are some of the thoughts I have:

1. VirtualBox Shared Folders
   Using the built-in shared folder features is really nice and easy to setup. The problems that I have encountered is that you will need to have special attention on the VirtualBox network adapter setup. If you use "Bridged Adapter" and you un-dock the laptop you will need to reselect the network adapter.
   Also, a big problem is that Windows 7's "User Account Control" default level does not allow execution of programs over network drives and (even worse) some older programs are unable to browse these network shares. Also, turning the UAC off is not recommended Windows practice.
2. Sharing local (host) partition with raw access
   Sharing a local (FAT or NTFS) partition, is another way. Creating a .vmdk partition requires a bit more work.
   But it seems that this have other problems, one being that VirtualBox either have to be executed as root or the user will have to be added to the "disk" group(which I suspect can cause other security related issues). Also I am not sure if mounting the same partition on the Host as well as on the Guest, would cause issues with concurrent reads/writes.
   Does anyone have success/experience with this?
   In relation to the concurrent read/write, would this be solved by setting the type of the .vmdk partition as "Shareable"?
3. Shared disk image
   Another solution, could be to create a disk(.vdi) image and mark it as "Shareable" in Virtualbox. Then mount this on the host using the network block driver. I have not been able to get this to work on Ubuntu 18.04 yet. Do anyone have any experience with this?

Any one have any ideas to solve this problem? Or any experience they could share?

[Martin]

VirtualBox shared folders are not using network functions, so they are note dependent to any network configuration.

[The man with only 1 arm]

VirtualBox shared folders are not using network functions, so they are note dependent to any network configuration.

Thank you for pointing this out, Martin! I can verify that my initial findings were incorrect. However, there is still the issue of the UAC, as Windows still "thinks" that this is a network connection.

[socratis]

What UAC issue? You'll need to describe the situation in a little bit more detail.

[The man with only 1 arm]

Hi Socratis!
Windows 7 (I think Vista and above) prevents the execution of exe files from network shares, when the default level is selected.
Some programs also have issues reading the content of files in the shared folder, unless the UAC level is lowered or turned off.
I ran into this issue and found an older ticket describing it well. Please check VirtualBox ticket #5732 (Many executables refuse to run fom Shared Folders). Sorry, unable to post URLs, as I just joined.
I have been able to replicate and confirm that this is still an issue.
If you google "virtualbox shared uac" you'll find a number of articles that describe this problem.

[socratis]

This has absolutely nothing to do with VirtualBox. Either use standard network shares, or don't use shared folders.

[The man with only 1 arm]

Hi socratis!
I didn't imply that this was an issue with VirtualBox. I do not have the insights to determine if this would be an issue with VirtualBox.
I can only assume that others might have similar requirements as I, and I am simply asking for guidance, word of advice and/or other's experience in relation to this.

[socratis]

and I am simply asking for guidance, word of advice and/or other's experience in relation to this.

Well, here's a small part of a larger article (that I've never polished enough to post) that was dealing with the issue:

Note 1: If you run "UpdateInstaller.exe" from a VirtualBox share that is not mapped (does not a drive letter assigned), you get the following error:

• Unable to assign a drive letter
  to the script path \\VBoxSvr\WSUS\client

Note 2: If you run "UpdateInstaller.exe" from a VirtualBox share that is mapped (has a drive letter assigned), you get the following error:

• W:\Client\UpdateInstaller.exe
  The specified path does not exist.
  Check the path and then try again.

Solution 1: Disable UAC control temporarily. Then run "UpdateInstaller.exe" from a mapped share. You can turn off the network if you don't feel protected enough.
Solution 2: Copy the whole "WSUS\Client" sub-directory in the VM. It's several GB.

Explanation
When a user connects to a network share, Windows tries to connect with two sets of credentials. This fails due to the UAC control. It is so by design. For references and further reading on previous reports and the reasoning behind it (read especially the Microsoft links):

• https://www.google.gr/search?q=the+spec ... ualbox.org
• viewtopic.php?f=7&t=48570
• viewtopic.php?f=7&t=40036
• https://www.virtualbox.org/ticket/5732
• https://support.microsoft.com/en-us/kb/303308
• https://support.microsoft.com/en-us/kb/2019185

[sundialsvc4]

I feel that synchronization problems could fairly quickly wipe you out if both VMs need to modify anything: they won't know about each other. Of course this will not apply if the resources are caused to be read-only.

If you need to have simultaneous read/write access to resources I suggest that you use a shared-file protocol such as NFS between the two VMs, such that one and only one of them "owns" the files and runs the server. Treat this exactly as you would on "real iron."

[oshunluvr562]

I'm sort of doing this now. It took a bit of doing, but it works. I use 5 VMs regularly for my work and wanted portability because I travel one or two weeks a month and need the VMs when I on the road. So I decided to store the VMs on my laptop but wanted to be able access them from my desktop.

Here's what I did:

1. 2 Linux hosts (Kubuntu 18.04 laptop and 16.04 desktop - soon to be upgraded )
2. VMs are all on an ext4 partition on the laptop
3. Laptop exports the VM partition using NFS
4. Desktop mounts the NFS share
5. Clicking on the .vbox file of each machine put it into the VirtualBox menu on the Desktop

That's it.

I had some trouble with the virtual drive paths because I initially mounted the NFS export to a different path. This wreaked havoc with the Virtual Media Manager. To get the VMs to work consistently, I adjusted the mount path of the desktop to match the laptop - both locations are now mounted at /mnt/vm_drive on their respective machines.

The one serious issue and this is a warning if you try this: One machine does not detect if the other is running a VM so it's possible to launch the VM twice on both machines. I did this once by accident and trashed the virtual hard drive. Luckily (and obviously) I had a backup of the VM. It would be useful if the VM had a simple lock file in it's folder so any machine could detect it was running and prevent this from occurring. There's probably a way to make that happen, at least on a Linux host.

The other issue I had at first is the annoying way VirtualBox seems to decides to take a random snapshot of a virtual drive every so often. This caused me a large headache at first because I could never get the snapshot to mount properly on the other machine, then I figured out all I had to do was click on the .vbox file and everything "just worked."

Eventually, I will figure out how to stop the snapshot thing. I tried the "delete the snapshot" but that just trashed the virtual drive.

Also these virtual drives are all dynamically sized type (most were converted from VMWare because I hate it) and it seems you can't convert them to fixed or make their size smaller. I did find a tool that runs in Windows that will do it supposedly, but I haven't tried it yet. One of the VMs was created by someone else who thought 500GB was a good idea <rolls eyes>. I'll probably end up creating new fixed-size drives and moving the data manually across the virtual drives so I can control the sizes.

Usage is when I return to the office from the road, I plug my laptop in and connect it to the network. When I need to use the VMs, I turn the laptop on remotely using wake-on-lan and mount the VM drive NFS export. Then I launch the virtual machines I need to use. When done, I kill all the VMs and power the laptop down via ssh.