Samba
File sharing is a very common use for servers…
in fact, I had Samba installed to my primary workstation for quite a long while before experimenting with a dedicated server or containers. Samba is very easy to set up too; a simple samba.conf file holds all of your configuration in a clean text-based format. No need for a web UI to access or configure your files: just mount the Share in your filesystem and go. This server was on my primary desktop, as I mentioned, which meant I didn’t actually have to connect to it to access my drive most of the time. If I was at my desk, the drive was physically plugged into my desktop; the sharing was more for phones or laptops.
Migrating to hosting the service in a container, and more importantly on a different machine, meant changing a few things in my setup. Getting the container was the easy part, a quick search and I had a ready-to-go server. The problem starts with ports; Samba communicates over port 445. Ports under 1024 are privileged, meaning nonroot users can’t bind to them. This meant one of two things: run as root, or preroute that port. I chose the latter, and set up some rather interesting rules using UFW that moved the port to unprivileged space.
After doing so, I could locate my server but had no way of authenticating. Normally Samba uses the account info saved to the OS. Because I was in a rootless container, it was more more complicated than that. In a rootless container, you run the service using a user account instead of root. When you do so, your orchestrator maps the root account within the container to your user account. This restricts the actions of the container on the host to be, at most, what you’re able to do outside of it. Any other accounts made within the container have no corresponding account outside of the container. This effectively meant that only root could manipulate the filesystem of the host; which is to say my Samba Share! I had to bite the bullet for now and accept that solution, creating a password for root and moving on.
Everything was operational: a Samba Share accessible with me-defined credentials that was both readable and writable from the container. There were two more nice-to-haves that I yet wanted, though. First was a nice connection point. I had been remoting to my server using the hostname my router gave it when I statically assigned it an IPv4. This did work with Samba, which needed me to use the actually IPv4. I didn’t have a nice solution to this yet, but it would linger with me for a minute...
The other was persistent mounting. When I boot my desktop, I want my Share to be mounted and ready to go. Normally this involves a quick edit to /etc/fstab to add the new drive as a mount at startup. However, this drive had credential requirements. The solution required creating a text document with the username and password in it, then restricting permissions to it. Members of a specific group would have read access to them, but only root would have access to write to them. I set the credentials file in my fstab, and it worked like a charm! The Share was mountable and unmountable by a user account, and it should mount on startup as well… keyword should. Despite some more investigation & consternation, I still have yet to successfully mount the Share on startup. I won’t say I’ve given up on the issue, but I’m going to give it some more time before tackling it again.
After it all I still had my Samba Share, but now hosted where it should be (on my server) and portable due to the containerization. The endeavor also gave me greater insights into managing privileged ports and my firewall, as well as the (secure) restrictions that running rootless containers imposes. At the end of it all, I was left wondering if I could make my other services more friendly to access too…