Good Morning from my Robotics Lab! This is Shadow_8472, with a stubborn-project update. Let’s get started!
Nextcloud as a project comes with a lot of strings and hooks. Every time I sit down to work on it, the feature creep closes in: multiple volumes for speed and capacity, MariaDB container so SQLite doesn’t choke serving clients, a pod for MariaDB to live in alongside Nextcloud, Redis for RAM caching (Out of my scope, but worth a mention), Ansible Vault for password management (automation tool I’d need a month to learn), podman secrets, Philomena image board software – not to mention the volumes I learned about the other week! As noted in previously, the container I’m using from docker.io can take care of itself, but it will work a lot better with even a few of these things.
In my ideal configuration, all my containers’ persistent data lives on GoldenOakLibry so my old, red laptop can take over on critical Podman containers when ButtonMash is booted to Debian for photo scanning duty. The big, hanging question then is if GoldenOakLibry’s internal HDD’s absolutely need to spin up to serve shares hosted on NAS volumes mounted from an external SSD.
HDD: Hard Disk Drive
NAS: Network Attached Storage
SSD: Solid State Drive
My initial tests involved verifying that a drive could be mounted externally, then rebooting the NAS. I was expecting either a 1 or a 50 second wait, but instead I kept hitting “Stale file handle” errors when I tried mounting the external share. My second round of trials a week or two later exhausted search pages worth of results to learn how NFS shares change a few invisible details when restarted. Either something wasn’t ready when needed during boot, or my client just needs a while to refresh those details. It works in the long run, and external shares are not dependent on internal disk spinup. Time to move on.
Having solved the last known problem, I started layering the bits I had solved while frustrated with the USB share. I prepared three Podman volumes: two for Nextcloud prioritizing high-capacity and speed, respectively, and one for an SQL database. A pod housing MariaDB (the SQL database) and Nextcloud containers mounts these volumes (!). Podman secrets safely injects the database password so MariaDB and Nextcloud can work together – not strictly necessary for my application, but a good habit to get in in case I go in the direction of creating images from existing containers. Once the cloud is running, I want to try adding an image board to view the pictures.
(!) NFS –as it turns out– does not appreciate a number of the acrobatics rootless Podman performs with Namespaces. I don’t have the specifics memorized, but when Podman makes a container, the host’s user ID is mapped to root within that container. Podman then assigns variations of the host’s user ID to non-root users within the container as defined by a namespace. The NFS protocol wasn’t designed with namespaces in mind. To NFS, it looks like you’re trying to access another user’s files – possibly without permission. While this reportedly doesn’t stop rootless Podman from working well over NFS over normal circumstances, there are a bunch of search results talking about the snag when working with container images over NFS. Based off my experiences for this post, the same appears to hold true for volumes.
Takeaway
As much as I wanted this to be the last installment, this issue is a post in and of itself, and I’m getting burned out again over trying to come back to it. I’ll try coming back to this in around a month or so.
Final Question
Have you successfully used Podman volumes over NFS? Please, do tell me all about it in the comments below or on my Socials.