Setting up a home NAS on Fedora Server 44 with OpenZFS, Cockpit, and Samba

Introduction

#

In this article, we’ll build a modern home NAS based on Fedora Server 44, the OpenZFS filesystem, and the Samba file server.

For a long time I used TrueNAS as my storage operating system. It’s a great system, but over time I came to the conclusion that, in my case, it’s overkill. My NAS does one job - storing files - so many of TrueNAS’s capabilities went unused. Meanwhile, everything else turned out to be more interesting and convenient to set up myself.

I chose Fedora Server as the foundation. We’ll get a full-fledged Linux system, the Cockpit web interface, the ZFS filesystem, and familiar SMB sharing.

Why Fedora Server instead of TrueNAS?

#

Before diving into the setup, I want to answer a perfectly logical question: why go with Fedora Server at all if you’re already using TrueNAS, or why not try any of the other ready-made NAS operating systems?

For a long time, I used TrueNAS as the primary operating system for my home NAS. It’s a great solution with a convenient web interface and lots of built-in features. Over time, though, I realized I was only using a small fraction of its functionality, and some of TrueNAS’s quirks started to bother me.

For me, a NAS is first and foremost a reliable data store. All the other services - Nextcloud, Immich, Jellyfin, Grafana, Docker, and others - run on separate servers and virtual machines. As a result, most of TrueNAS’s capabilities simply went unused.

Fedora Server, by contrast, provides a clean, modern Linux system without unnecessary components. This gives several advantages:

• full control over the operating system;
• always up-to-date software versions, but without the quirks of arch-like systems;
• the ability to choose the services you actually need;
• convenient administration through Cockpit;
• full support for OpenZFS;
• no restrictions typical of specialized NAS distributions.

I agree that this approach requires a bit more time for the initial setup and knowledge slightly above basic mouse-clicking skills. But in return, you get a maximally flexible system that’s easy to adapt to your own needs, without depending on the quirks of a specific NAS platform.

That’s exactly why I chose Fedora Server 44 as the foundation for my home file server.

Preparing Fedora Server

#

System update

#

sudo dnf update -y

In modern RPM-based distributions, the dnf update command already includes the functionality of the old dnf upgrade.

Installing the necessary packages

#

sudo dnf install -y \
tar gzip curl unzip git procps-ng findutils nano \
cockpit-bridge coreutils attr hostname iproute glibc-common \
systemd nfs-utils samba samba-client samba-common-tools

Additional tools

#

sudo dnf install -y lm_sensors cockpit-sosreport
sudo sensors-detect

sudo systemctl restart cockpit.socket

Installing Cockpit Sensors

#

sudo wget https://github.com/ocristopfer/cockpit-sensors/releases/latest/download/cockpit-sensors.tar.xz
# 
sudo mkdir -p /usr/share/cockpit/sensors
# 
tar -xf cockpit-sensors.tar.xz cockpit-sensors/dist
# 
sudo cp -r cockpit-sensors/dist/* /usr/share/cockpit/sensors/
#
rm -rf cockpit-sensors cockpit-sensors.tar.xz

sudo systemctl restart cockpit.socket

Installing OpenZFS

#

Add the repository:

sudo dnf install -y https://zfsonlinux.org/fedora/zfs-release-3-1$(rpm --eval "%{dist}").noarch.rpm

Install the headers for the current kernel:

sudo dnf install -y kernel-devel-$(uname -r | awk -F'-' '{print $1}')

Install OpenZFS:

sudo dnf install -y zfs

Load the module:

sudo modprobe zfs
# Tell the system to load the module on boot 
echo zfs | sudo tee /etc/modules-load.d/zfs.conf

Just to be safe, let’s check that ZFS will work after a system reboot:

sudo reboot

Verify the installation:

zfs version

Creating a ZFS pool

#

Let’s create a mirrored pool from two disks:

lsblk # list the disks

sudo zpool create -m /srv data mirror /dev/sda /dev/sdb

Important: don’t use /mnt as the ZFS mount point for publishing via Samba. On Fedora Server 44 with OpenZFS 2.4.x, Samba can throw a canonicalize_connect_path failed error. In my case, SMB sharing didn’t work with the /mnt directory. Using /srv instead, everything worked right away.

sudo zpool create -m /srv data mirror /dev/disk/by-id/ata-XXXX /dev/disk/by-id/ata-YYYY

Let’s create a dataset:

sudo zfs create data/media

Check that the pool and dataset were created:

zpool status
zfs list

Let’s enable compression:

sudo zfs set compression=lz4 data

Let’s assign an owner:

sudo chown -R stilicho:stilicho /srv/media

Here I’ll add a small remark (forgive me, Erich Maria). In your shoes, I’d reboot the system and check once more that the pool and dataset mount correctly after a reboot:

sudo reboot
zpool status
zfs list

If, after rebooting, the pool didn’t mount, run the following commands:

sudo systemctl enable zfs-import-cache.service
sudo systemctl enable zfs-import-scan.service
sudo systemctl enable zfs-mount.service
sudo systemctl enable zfs.target

Now:

sudo reboot

and check the result.

Configuring SELinux

#

sudo semanage fcontext -a -t samba_share_t "/srv/media(/.*)?"
sudo restorecon -Rv /srv/media

This command adds an SELinux rule that assigns the samba_share_t context type to the /srv/media directory and all its contents. This lets Samba serve access to this directory over the network.

Let’s break down the command piece by piece:

sudo semanage fcontext -a -t samba_share_t "/srv/media(/.*)?"

• sudo - run the command with administrator privileges.
• semanage - utility for managing SELinux policies.
• fcontext - manage file contexts.
• -a - add a new rule.
• -t samba_share_t - assign the SELinux type samba_share_t, intended for Samba shared folders.
• "/srv/media(/.*)?" - a regular expression:
  • /srv/media - the directory itself;
  • (/.*)? - all files and subdirectories inside it.

After adding the rule, you need to apply the new context to existing files:

sudo restorecon -Rv /srv/media

• restorecon - applies SELinux contexts according to the rules.
• -R - recursively processes all nested directories and files.
• -v - prints information about all changes.

Verification:

ls -Zd /srv/media

Expected result:

system_u:object_r:samba_share_t:s0 /srv/media

Configuring Samba

#

Let’s create a separate local Linux user that will be used to access the SMB share:

sudo useradd samba
#
sudo smbpasswd -a samba

Let’s set permissions for the samba user on the dataset we’re going to share:

sudo groupadd media # create a dedicated group for sharing
# add our users to it
sudo usermod -aG media stilicho 
sudo usermod -aG media samba
# set permissions on the dataset for the media group's users
sudo chown -R stilicho:media /srv/media
sudo chmod -R 775 /srv/media
sudo find /srv/media -type d -exec chmod g+s {} \;

Let’s create the Samba share. Add the following to /etc/samba/smb.conf:

[share]

    comment = Shared Network Folder
    path = /srv/media
    browseable = yes
    read only = no
    valid users = samba
    force group = media
    create mask = 0644
    directory mask = 2755

Let’s start the services:

sudo systemctl enable --now smb nmb
sudo systemctl status smb

Let’s check:

smbclient //localhost/share -U samba

If everything is set up correctly, the Samba console will open.

Connecting from Windows

#

Open File Explorer and enter:

\\SERVER-IP-ADDRESS\share

Enter the Samba user’s login and password.

Create a test folder and file, then make sure they’re created successfully and remain accessible after the server restarts.

Conclusion

#

As a result, we now have a full-fledged home NAS on Fedora Server 44 with the OpenZFS filesystem, the Cockpit web interface, and the Samba file server. This approach provides full control over the system and data storage without being tied to specialized NAS distributions. At the same time, Fedora remains an ordinary Linux system that can easily be extended with any services as needed, which is exactly what we’ll do in the next articles.