Grant McLravy In my last blog post (approximately 4 months ago), I talked about the build process and the software installation of TrueNAS, an open-source Network Attached Storage (NAS) software based on FreeBSD. Since then, I have switched away from TrueNAS to Ubuntu Server. I genuinely liked a whole lot of TrueNAS, but there were several reasons that I switched to Ubuntu:
Reason #1 – TrueNAS is designed as an OS for storage appliances
When I picked TrueNAS as the operating system for my server, the primary goal was to be a Network Attached Storage (NAS) device to pull my terabytes of data off of Google Drive. As I started to play with server management as a hobby, the goal changed. In the business world, we call this “scope creep” – where the initial request is something manageable but additional feature requests end up pushing the system further than it was designed to be pushed.
TrueNAS works very well as a simple way to set up ZFS pools with a web interface. It also has some cool ways to set up preconfigured software packages in FreeBSD jails. These FreeBSD jails gave me a taste of the types of software I could be playing with:
I started with Nextcloud, then Home Assistant, then Plex, then GitLab. I was obsessed. However, these preconfigured jails were often old versions of software that was back-ported to FreeBSD. Community support for these versions was not as solid as support for other native operating systems. This didn’t bother me at first, because I was busy playing with all the cool new features of TrueNAS.
Reason #2 – I’m not scared of CLI anymore
As I was trying to get TrueNAS to work for increasingly complex workflows, including automation, I had to dip my toes into the command line. One of the reasons I had chosen TrueNAS in the first place was to avoid the command line, but Mr. Scope Creep necessitated pushing the OS past the web-GUI’s guardrails. I needed to manually move some files into my Nextcloud directly. Guess I needed to learn how to manipulate files using the CLI. (Rsync is a really cool command) I wanted to sync items directly from Google Drive to Nextcloud – turn out learning Rclone commands make it way easier to manage cloud storage. What used to take 10 to 15 click in a GUI can be accomplished with one command. Combine that with “cronjobs” – automatically running a specific command at a specific time – and I could automate processes far more simply than with a GUI or a desktop environment.
I found myself SSH-ing into my server to manipulate things from the command line far more than I pulled up the web interface.
Reason #3 – I dipped my toes in a little bit already
TrueNAS includes the bhyve hypervisor for installing virtual machines on your server. When I was reading tech blogs to find new cool software to install on my server, I discovered Tailscale. There was a FreeBSD port of the software, but I was unable to get it to work properly. I was itching to try it out, so I created a quick Ubuntu VM to test it out. I fell in love with Tailscale – more on that in a future post but I wasn’t able to run it natively on my server. I also got used to the Linux command structure through some of the fiddling I did with that Ubuntu VM.
While playing with my Ubuntu VM, I also discovered the joys of a certain containerization format.
Reason #4 – Docker is incredible
Docker has not been ported to FreeBSD successfully yet, so I was unable to run containerized applications. The FreeBSD jail plugins for TrueNAS were often woefully out of date community ports, so I was forced to read documentation explaining how great this new feature was that I did not have. I learned about the Docker format when I installed Nginx Proxy Manager to test out combining a reverse proxy with Tailscale. (More on that later) Especially when deploying it with Docker compose involved setting up one config then running one command and an entire application was up in a matter of seconds.
Soon all my FreeBSD jails became Docker containers in my Ubuntu VM. Then I had to mount the files from my main storage device into my VM to get them to be accessible in my containerized environment. I asked myself – what if I could just run ZFS on Ubuntu?
With a simple command:
sudo apt install zfsutils-linux
I was able to get ZFS running in my Linux VM. I had proven it could work – I just needed to make the switch. Originally I had considered using ZFS boot, but after reading about what could do wrong if I experience disk corruption on my main pool, I decided to install Ubuntu on the 120GB SSD I used as a read-write cache for my primary pool.
Docker Server vs. a Server with Docker
I have transformed my server into a Docker server – every crucial app is now containerized and was created from one central Docker Compose file, including the blog you’re reading this post on. In future posts, I’ll discuss some of the intricacies of how I could get this system to work, and some of the resources I found particularly valuable while setting up this server.
