There was also a related discussion here: https:// forum. qubes-os. org/t/single-file-storage-for-app-vms/21724,. However, transferring encrypted containers between VMs doesn’t appear very secure or efficient.
As far as official methods go, there’s no way to have read-write storage that’s accessed by multiple qubes simultaneously. At least I haven’t been able to find an official solution like that.
A decade ago I had to deal with this on a baremetal server with mutual storage with multiple blades, this is the same thing as exposing the same storages to multiple qubes.
Using something like glusterfs would work, but it’s a real pain to setup, basically you need to create a cluster with all the operating system mounting the filesystem, they have to communicate over the network to track the current state / locks of the filesystem, so they can work on it synchronously. This has poor performance too ^^
I suppose this is achievable within Qubes OS, but you would need to connect all the qubes to a central nodes (or even together?) which defeats containerization…
Not sure if possible by directly operating block devices, but if you set up VM0 as a fileserver accessible via qrexec I think it can work.
Actually this might be even easier to do if VM0 hosts git repository, not fileserver, but I guess it’s up to you at this point.
What I mean is:
template
Holds whatever configuration you need to run e.g. a fileserver, like service file but it is deactivated. Does not have storage device attached to it.
AppVM (VM0)
Holds script that starts the fileserver on boot in /rw/config. Storage device is attached to this vm. Fileserver is configured to only allow read access.
Other AppVMs (VM1, VM2, etc.)
Qubes policy allows them to connect to VM0’s fileserver port. When needed (or upon boot via /rw/config) run qvm-connect-tcp to connect.
Why bother with those at all? All of them are made to allow read-write access. Since OP wants to only write from a single qube, using this qube as the fileserver itself is easier, and I expect that configuring something like nginx to serve files readonly with no authentication or authorization (handle this in qubes policy) would be easier as well.
Even accessing it is easier that way. No mounting required, just curl, wget, or git clone
p.s. Scratch that all, you’re probably correct, especially for the larger files.