Hello everybody
Let me first give some context about the goal and what I tried so far.
My goal is to replace some SAMBA shares with a Nextcloud instance. Since I’m starting from scratch with all this container business, I decided to go with podman rather than docker. Also, my data is currently stored on storage server in some ZFS volumes. I’d like to use this storage server to back my persistent storage for the container data.
As usual, when I’m prototyping a new service, I start as simple as possible and gradually build up to the solution I want. I started out by spinning up a minimal Nextcloud instance with integrated DB using locally stored volumes. Then added a DB container. That worked well.
Then I started looking mapping my storage server into my containers. Chose NFS for this since it is simple, low overhead and I already know how to use it. That’s where I started hitting some walls. First, I learned that the :Z confinement with SELinux does not work on NFS shares (See also this Github Issue). I decided to just forego confinement for the time being. Next I had some permission problems and learned about “podman unshare” and tried to chown the directories to the correct sub-uids. However, the NFS server did not like that at all. Naturally, it knows nothing about the sub-uids on the podman host. I got it to work when using root and “norootsquash” on the NFS share. But now I’ve lost most of the benefits of using podman in the first place. All I achieved is depriving myself of all the very comfy docker compose files that exists for Nextcloud. All this gives me the strong feeling that I’m barking up the wrong tree here.
So, after all this exposition, my question: What is the current best practice or sanctioned way of attacking networked storage to a podman container? Note that this is specifically for user data, not for container images.
I’m grateful for any pointers towards a better solution.
Cheers
Gilgwath