This discussion pops up every couple of days. It's a somewhat glaring omission in the design of Proxmox, but it does make some conceptual sense.
In an enterprise setting, you would never even encounter this problem, as you'll have a big cluster of interconnected machines, and storage is managed as yet another networked service. You can obviously do the same thing in a single-node Proxmox instance that you operate in a home lab. And for less experienced users, that's almost certainly the best option. Sticking with the official design is much safer, than intentionally breaking all the rules. If you want to do things the Proxmox-way, then create a container that runs both an SMB and an NFS server. Then configure all other systems to only ever access your files using network protocols. Easy to configure if you follow any number of online guides published in the last couple of decades.
But if you don't like the idea of combining storage with the container instance, Proxmox can be coerced into non-standard behavior that maintains storage outside of the containers and VMs. It works fine, if you understand its limitations. But you have to be OK with managing things yourself. If it breaks, you get to keep both pieces...
Create a new ZFS file system (preferably on a dedicated ZPool, if you happen to have spare drives). I'll give an outline of the commands here, but in practice you might want to tweak some of the parameters:
Code:
zfs create rpool/userdata
It is perfectly fine to use unprivileged containers, but you can't mix privileged and unprivileged nor can you access the same data from both the host and unprivileged containers. If that is a problem for you, then use "idmap" entries in your containers to selectively map a range of user ids to something that everybody can agree on. If you didn't mess with the "idmap", then you instead need to adjust the permissions:
Code:
chmod 100000:100000 /rpool/userdata
Next, you might be tempted to use bind mounts to bring this file system into the containers. Don't! This is were we need to break the rules. Conceptually, Proxmox thinks of bind mounts as resources that are owned by the container. If you have bind mounts, then it can no longer do snapshots, as it doesn't know how to snapshot a shared resource. Backup/restore is also potentially confusing. Instead, we should inform Proxmox, that this is a foreign resource. Conceptually, it's like NAS storage. Something that isn't owned by any of the containers or VMs, and that is managed separately by some other entity.
This requires editing the container definitions.
Code:
pct stop 101
vi /etc/pve/lxc/101.conf
Add this line:
Code:
lxc.mount.entry: /rpool/userdata userdata none rbind,create=dir
And of course start your container again:
Repeat for all the other containers that should have access to shared storage.
Your next problem is going to be that you are fully responsible for managing this storage. None of the niceties that Proxmox usually takes care of are available. In particular, this means that Proxmox won't bother to create backups. Fortunately, that's relatively easy to do manually. You probably want a script and/or cron job, that does something along these lines:
Code:
zfs snapshot rpool/userdata@backup
zfs set snapdir=visible rpool/userdata
proxmox-backup-client backup userdata.pxar:/rpool/userdata/.zfs/snapshot/backup --ns userdata
zfs destroy rpool/userdata@backup
A more real-life version of this script would likely maintain a rolling archive of historic snapshots, but that's outside the scope of this comment.
If you want to import the files into a VM instead of into a container, take a look at this
discussion on virtiofsd. Looks quite promising, but appears to still have a few rough edges.
Is this all worth it? Hmm, hard to say. By definition, it only makes sense if you don't already have a NAS solution, which obviously would be a more natural fit. So, that puts it firmly into the realm of homelabs. For those, it might make sense. After all, it's relatively easy to undo, if it stops working. At that point, you simply install a network filesystem and go the traditional route. And in the meantime, the direct mounting option does simplify some things. So, give it a try and report back, but don't expect Proxmox to ever officially support this hack.
