The topic I used Cockpit instead of a full NAS OS, and my spare Linux box finally made sense… is currently the subject of lively discussion — readers and analysts are keeping a close eye on developments.
This is taking place in a dynamic environment: companies’ decisions and competitors’ reactions can quickly change the picture.
When it comes to building a Network-Attached Storage server, you’ve got a plethora of distributions to choose from. TrueNAS, Unraid, and OpenMediaVault are the most common platforms for storage servers, while Rockstor and XigmaNAS are obscure heavy-hitters. If you’re willing to branch out to virtualization platforms, you can also deploy a VM on Proxmox and pass your SATA controller to it for a custom NAS.
Or, you could opt for a DIY backup rig that features only the bare minimum number of NAS-centric packages – which is something I recently did while attempting to turn an N100 mini-PC into a storage-heavy workstation for my home lab. And truth be told, Cockpit + Ubuntu Server are a terrific pair for makeshift NAS setups, especially in a resource-constrained environment.
The NAS ecosystem has its fair share of cool operating systems
Considering that I wanted to use a mere N100 system with 8GB of memory, I wanted to avoid distributions that hog too many resources. As such, distros with GUI elements were out of the question. After going back and forth between Ubuntu Server and a barebones Debian version, I decided to opt for the former after seeing a bunch of forum threads about DKMS being broken on Debian, while Ubuntu Server ships with ZFS support natively, so I won’t run into weird compatibility problems out of the blue.
Now, before you condemn me for choosing Ubuntu, let me add that Ubuntu Server is not the same as its Desktop variant. It doesn’t ship with the extra bloat that comes pre-loaded with Ubuntu Desktop – to the point where it doesn’t even enable SSH by default, so you’ll need to install it as an additional package during the initial setup wizard. Anyway, installing the distro was a piece of cake, and since I wanted to configure my NAS environment from my main PC, I let the distro install OpenSSH server.
With the Ubuntu Server installation process complete, I logged into the soon-to-be NAS over SSH. My gameplan was to arm it with NAS packages before pairing it with Cockpit and configuring everything from its neat web UI. I ran sudo apt install cockpit curl samba nfs-kernel-server cockpit-bridge zfsutils-linux coreutils -y to grab all the packages I’d need for my makeshift NAS, so the first step went by without a hitch. I also executed sudo zpool create diypool sdb to spin up a new ZFS pool on a drive I’d salvaged from an old PC. Then, I ran sudo systemctl enable –now cockpit.socket to get my Cockpit instance up and running, and switched to its web UI by typing the IP address of the mini-PC followed by port number 9090.
But since Cockpit had no way of controlling the NAS packages on my DIY storage server, it was time to look into some extra plugins. Grabbing the Cockpit storage plugin was as easy as running sudo apt install cockpit-storaged. I’d heard good things about the file-sharing plugin from 45Drives, but I had some issues installing the repo the conventional way. Whether I tried to install it from the repo or attempted to build it from scratch, the installation would end up failing. Weirdly enough, I found a workaround that involved downloading the RPM version of the package via wget https://github.com/45Drives/cockpit-file-sharing/releases/download/v3.2.0/cockpit-file-sharing-3.2.0-1.el8.noarch.rpm before using the alien tool to convert (and install) it as a typical DEB packages via sudo alien -i cockpit-file-sharing-3.2.0-1.el8.noarch.rpm.
Switching to Cockpit’s web UI, I went through the Storage tab to check on my ZFS pool, which appeared without any issues. Likewise, I used the File Sharing section to deploy an SMB share on my freshly-configured ZFS pool, and once I’d tweaked the user permissions, I was able to access it from my PC.
So far, I’ve deployed a pretty decent file-sharing and (secondary) backup server. But considering my NAS transfers didn’t consume that many resources, I figured I could try turning it into a container-hosting hub as well. I was tempted to opt for Canonical MicroCloud, but since Cockpit has an official plugin for Podman environments, I figured I could stick to this all-in-one management UI instead of fiddling between different web interfaces.
Luckily, the plugin was fairly easy to configure, as all I had to do was run sudo apt install cockpit-podman -y, and watch the package manager run its magic. After refreshing Cockpit, the Podman containers tab appeared in its UI, and I grabbed a couple of images with its built-in image downloader. Within a few minutes, I had a collection of Podman containers deployed on my makeshift. I also wanted to tinker with the Cockpit VM plugin, but since the host couldn’t handle dedicated virtual machines, I decided to leave that experiment for another time.
As much as I adore my fully-customized NAS, I’ll stick to my bulky TrueNAS chassis for my primary backup server. Plus, I’ve already created a 3-2-1 backup pipeline that’s powered by this beast of a server distro, and unless iXsystems pulls the same anti-consumer measures as Broadcom did with ESXi back in 2025 (yes, I’m still salty about that), I doubt I’ll move away from this setup. That said, my DIY storage rig is perfect for maintaining redundant copies of essential data. After all, there’s no such thing as too many backups.