Ubuntu vs Fedora for Home Server: I Ran Both for 6 Months and Here’s What Actually Matters

I Needed a Home Server OS and Couldn’t Stop Second-Guessing Myself

The machine I was setting up wasn’t impressive — a decommissioned Dell OptiPlex 7050 with 16GB RAM, a 500GB NVMe I had lying around, and an old spinning disk I repurposed for media. The workload: Plex with hardware transcoding, Nextcloud for file sync, Pi-hole for DNS filtering, and a handful of Docker containers running things like Vaultwarden and Uptime Kuma. Nothing exotic. But I spent two weeks longer than I needed to picking the OS because I kept reading takes that didn’t match what I was actually trying to do.

The “Ubuntu is stable, Fedora is modern” framing is the one that kept tripping me up — because it implies you should pick Fedora if you want newer software and Ubuntu if you want things to just work. That’s not wrong exactly, but it completely misses the texture of what breaks. The question I actually needed answered was: at 11pm when Pi-hole stops resolving and Plex is throwing a transcoding error, which OS makes the debugging process less miserable? That’s a different question than “which has newer packages.” One is about release philosophy, the other is about the quality of Stack Overflow answers, the breadth of official documentation for self-hosted apps, and whether your problem has been hit by ten thousand other people or four.

There’s also a practical difference that nobody puts in the comparison articles: Ubuntu LTS pins you to package versions for up to five years, which sounds safe until you’re trying to run Nextcloud Hub 8 and the recommended PHP version isn’t in the default repos. Fedora ships newer everything by default, but the EOL window is roughly 13 months per release. That means you’re doing a distro upgrade — not just package updates — every year if you’re being responsible. On a desktop, that’s fine. On a home server you’ve spent three weekends configuring, it’s a different calculus entirely.

My actual setup ended up looking like this before I’d even chosen the OS:

# Services I needed running reliably
plex          → hardware transcoding via /dev/dri passthrough in Docker
nextcloud     → AIO container with Redis and Postgres backing it
pihole        → bare metal or lightweight container with host networking
vaultwarden   → Docker, exposed via Caddy reverse proxy
uptime-kuma   → Docker, port 3001

# The constraint that mattered most
/dev/dri access for Intel Quick Sync — kernel + driver version matters here

That /dev/dri line is what actually forced the comparison to get concrete. Intel Quick Sync support in Docker requires a recent enough kernel and the right i915 driver version. On Ubuntu 22.04 LTS you’re on kernel 5.15 by default — which works, but you’re pulling HWE kernels to get better Quick Sync support on 12th gen Intel. On Fedora 39/40, you’re on 6.x kernels out of the box. That’s a real difference for this specific hardware, not a theoretical one.

One side note: if you’re building out your home server setup with any kind of automation — Ansible playbooks, shell scripts, Dockerfile templating — I’ve been using AI-assisted tooling to speed up the boilerplate. The Best AI Coding Tools in 2026 has a solid rundown of what’s actually useful for sysadmin-adjacent work right now, beyond just writing application code. Some of those tools are genuinely good at generating Caddy configs and docker-compose files that don’t immediately blow up.

The Setup I Was Working With

My Intel NUC (the NUC10i5FNH specifically) has been running 24/7 for over two years. 16GB of RAM, a 2TB Samsung 980 Pro NVMe — it’s genuinely the sweet spot for a home server that isn’t trying to be a homelab hypervisor. I want to be clear about the scope here because “home server” means wildly different things to different people, and the Ubuntu vs. Fedora question has a completely different answer depending on what you’re actually running.

The workload stack is pretty ordinary by design. Docker Compose for everything containerized — Vaultwarden, Nextcloud, Jellyfin, a few internal dashboards. Samba shares pointed at a 4TB external for media. Tailscale for remote access because I refuse to punch holes in my router’s firewall. Occasional Ansible playbooks pushed from a MacBook when I want to make config changes without SSHing in manually. Nothing exotic. The kind of setup where you want the OS to disappear into the background and just work.

# Typical docker-compose invocation I run after any OS reinstall
# to validate the environment is sane before deploying actual stacks
docker compose version  # need 2.x, not the old docker-compose v1
docker info | grep -E "Storage Driver|Cgroup"
# Fedora gives you overlay2 + cgroupv2 out of the box
# Ubuntu 22.04 also does, but 20.04 was still on cgroupv1 — caught me off guard once

This is not a hypervisor lab. I’m not running Proxmox, not doing nested VMs, not trying to simulate a datacenter in my office. No ZFS pools, no RAID — just a single fast NVMe with snapshots handled by Tailscale’s sync and occasional rsync to a NAS elsewhere on the network. If that sounds boring, good. Boring infrastructure for a home server means you actually use it instead of maintaining it. The interesting question is which distro gets out of your way faster when you just want the thing running.

Hardware compatibility was never a real concern with the NUC — Intel NICs, Intel graphics, no exotic firmware blobs needed. Where the distro choice actually started mattering was around package freshness, systemd unit behavior, and how much the default install fights you when you’re trying to run rootless containers or tweak kernel parameters. Those are the friction points I ended up caring about, not whether the installer looked pretty.

Installing Both: Where the First Impressions Actually Diverge

The thing that caught me off guard with Ubuntu Server 24.04 LTS was how opinionated the Subiquity installer has gotten. It pushes LVM on by default, which sounds reasonable until you’re setting up a NAS-style home server and you just want straightforward partitions you can mentally track without running lvdisplay every time you forget what’s mounted where. You can override it, but it’s buried in the storage configuration screen — not the first option you see. The other thing Subiquity drops in without fanfare is cloud-init. On a home server that you physically own and just installed from a USB stick, cloud-init resetting your hostname on first boot or generating unexpected SSH keys is the kind of “wait, what just happened” moment that sends you down a 45-minute debug rabbit hole at 11pm.

Fedora Server 40 uses Anaconda, which feels older but is arguably more transparent. You click through disk partitioning, networking, and user setup in a way that maps directly to what ends up on disk — no surprises. The standout here is Cockpit. It gets installed and enabled at port 9090 by default, and for a home server this is genuinely handy. You can immediately open a browser, check disk usage, run journal logs, and manage services without SSH-ing in and remembering which systemd command does what. I was skeptical of it until I was troubleshooting a failing service from my phone while my laptop was charging across the room.

Package availability is where the daily-use difference becomes real. On Ubuntu, Docker is a first-class citizen in the repos:

sudo apt update && sudo apt install -y docker.io docker-compose
# docker.io 24.x ships in Ubuntu 24.04 main
# docker-compose here is v1 syntax — if you want the plugin version:
sudo apt install -y docker-compose-plugin

Fedora made a deliberate choice to ship Podman as its container runtime instead of Docker. That’s a fine call for a lot of workloads, but if you have existing Docker Compose files, Makefile targets that call docker, or you just want Docker CE specifically, you have to add the upstream repo manually:

# Add Docker's own repo — Fedora's default repos don't carry docker-ce
sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/fedora/docker-ce.repo
sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
sudo systemctl enable --now docker

That extra repo step isn’t a dealbreaker, but it does set the tone for Fedora’s broader philosophy: the distro has opinions about what tooling you should use, and Docker isn’t one of them. If you’re comfortable with Podman and its podman-compose workflow, Fedora’s day-one experience is actually cleaner. If you’re copying compose files from tutorials that all assume the docker binary, Ubuntu saves you friction. The honest trade-off is that Ubuntu’s docker.io package trails Docker’s upstream releases by a few months, while Fedora’s Docker CE repo pulls current builds directly from Docker Inc.

Docker vs Podman: The Biggest Practical Friction Point on Fedora

The thing that bit me hardest when I switched a home server from Ubuntu to Fedora was not the package manager or the release cadence — it was containers. Fedora ships Podman as the default and genuinely pushes you toward it. Rootless out of the box, no daemon process to babysit, and SELinux actually cooperates with it in a way that Docker never quite managed on Fedora without extra config. On paper, that sounds like a win. In practice, if your home server workload is “I found this docker-compose.yml on GitHub and I want it running by tonight,” you are in for friction.

The core issue is that basically every self-hosted project tutorial you find — Nextcloud, Jellyfin, Vaultwarden, Gitea, whatever — ships a docker-compose.yml that assumes Docker semantics. podman-compose exists and handles maybe 80% of cases, but that remaining 20% will ambush you. The most common gotcha: volume mounts on Fedora with SELinux enforcing will silently fail or throw permission errors unless you append the :z or :Z flag. :z means the volume is shared between containers, :Z means it’s private to that specific container. Miss this and you’ll spend an hour debugging why your container can’t read its own config files.

# What the compose file you downloaded looks like
volumes:
  - ./config:/app/config

# What it needs to look like on Fedora + SELinux
volumes:
  - ./config:/app/config:Z

Networking is the other place podman-compose diverges quietly. Podman’s default network mode in rootless contexts uses a user-level network namespace, which means inter-container DNS works differently than Docker’s bridge networking. Services that reference each other by container name sometimes don’t resolve the way the compose file expects. I’ve had to drop in explicit --network flags or switch to podman network create and manually attach containers. None of this is impossible — it’s just not in any README you downloaded.

If you want Docker CE on Fedora, it works. I’ve done it. But it genuinely feels like you’re overriding the distro’s opinion rather than working with it:

sudo dnf config-manager --add-repo https://download.docker.com/linux/fedora/docker-ce.repo
sudo dnf install docker-ce docker-ce-cli containerd.io
sudo systemctl enable --now docker
# Then add yourself to the docker group so you're not sudo-ing everything
sudo usermod -aG docker $USER

It installs cleanly and runs fine. But you’ve now got Docker’s daemon running alongside Fedora’s Podman tooling, and if you also have any Podman containers, you’re managing two separate container runtimes with separate image stores. That’s not chaos, but it’s unnecessary complexity for a home server where simplicity is the whole point.

Ubuntu is just easier here, and I say that as someone who prefers Fedora’s release model. On Ubuntu, you either grab docker.io from the apt repos (sudo apt install docker.io docker-compose) or add Docker’s official PPA for the CE version — either way your docker-compose.yml files run without modifications. No SELinux label flags, no daemon configuration fights, no rootless namespace weirdness to work around. If your primary home server use case is running other people’s compose stacks, Ubuntu removes an entire category of debugging. Fedora is worth the tradeoff if you’re running your own containers and want the security model — but go in knowing the tax you’re paying.

SELinux vs AppArmor: The Security Layer You’ll Forget About Until It Burns You

The first time Samba silently refused connections on my Fedora home server, I spent 45 minutes checking firewall rules, smb.conf syntax, and user permissions before realizing SELinux had been quietly dropping packets the entire time. No log message in /var/log/samba/. Nothing in journalctl -xe that screamed “this is the problem.” Just permission denied, over and over. That’s the thing about SELinux — it doesn’t fail loudly. It just fails, and you have to know to look for it.

Fedora ships with SELinux in enforcing mode by default, and that’s technically the correct security posture. It’s mandatory access control on top of standard Unix DAC permissions, meaning even root can’t do certain things without the right SELinux context. But for Samba specifically, here’s what you actually have to run before your shares work:

# Allow Samba to serve home directories
sudo setsebool -P samba_enable_home_dirs on

# Allow Samba to share arbitrary paths
sudo setsebool -P samba_export_all_rw on

# Set the right context on your share directory
sudo chcon -t samba_share_t /your/share/path

# Make the context survive a relabel (chcon alone doesn't persist restorecon)
sudo semanage fcontext -a -t samba_share_t "/your/share/path(/.*)?"
sudo restorecon -Rv /your/share/path

And NFS has its own set of booleans — nfs_export_all_rw, use_nfs_home_dirs — that you’ll discover one by one as services mysteriously refuse to behave. The audit log at /var/log/audit/audit.log is where the real denials live, and audit2why can decode them if you remember to use it. I didn’t remember for the first hour. The tool audit2allow will even generate policy modules for you, which is both helpful and slightly terrifying.

Ubuntu’s AppArmor takes a completely different philosophy. Profiles are path-based, written in a syntax that’s almost readable English, and the default profiles for common services like Samba, nginx, and MySQL are loose enough that they rarely block normal usage out of the box. When something does get blocked, aa-status shows you which profiles are enforcing, and aa-complain /etc/apparmor.d/usr.sbin.smbd drops a service into logging-only mode so you can figure out what it needs. You can actually read and understand an AppArmor profile without a PhD in mandatory access control policy writing.

• SELinux coverage: process-level, object-level, network ports, IPC — extremely granular. A compromised process is genuinely contained.
• AppArmor coverage: file paths, network access, capabilities — solid for most threats, but less granular than SELinux at the process level.
• Debugging SELinux: ausearch -m avc -ts recent | audit2why — you need to learn this command or you will suffer.
• Debugging AppArmor: journalctl -k | grep apparmor — that’s it, it’s in the regular journal.

My honest take after running both: SELinux on Fedora is genuinely better security, and if you’re running services exposed to the internet or handling other people’s data, the extra confinement is worth the learning curve. But on a home server where you’re the only user, your threat model is different. You’re not protecting multi-tenant data — you’re mostly making sure nothing from the internet pivots into your media files. AppArmor handles that well enough, and you’ll spend the hours you would have burned on SELinux troubleshooting on something that actually improves your setup. If you do go Fedora, at minimum install setroubleshoot-server — it translates AVC denials into human language and saves you from the audit log spelunking.

Package Freshness: When It Actually Matters and When It Doesn’t

The kernel version argument is the most overused point in the Ubuntu vs Fedora debate, and the numbers don’t support it anymore. Fedora 40 launched with kernel 6.8. Ubuntu 24.04 LTS also shipped with kernel 6.8. I’ve seen people make the “Fedora has newer kernels” case without checking that both distros have converged here for recent releases. Where there’s still a real gap is in things like systemd versions — Fedora 40 shipped with systemd 255, Ubuntu 24.04 shipped with 255.4 too, but Fedora pulls in minor revisions faster. For a home server, none of this matters unless you’re chasing specific driver support for new hardware.

Where Fedora genuinely pulls ahead on freshness is the supporting tooling around modern filesystems and system management. If you’re running Btrfs (which Fedora defaults to on desktop installs), you’ll get newer btrfs-progs faster. The same applies to cockpit — Fedora’s version is typically weeks ahead. If you’re managing your home server through Cockpit’s web UI, that matters in practice because UI features and storage management improvements land there first. I noticed the session recording feature in Cockpit worked cleanly on Fedora before Ubuntu’s version had it packaged properly.

Ubuntu’s real packaging advantage isn’t about kernel versions — it’s about the ecosystem of software that explicitly targets Debian/Ubuntu. The clearest example: if you want to self-host Nextcloud, snap install nextcloud on Ubuntu 24.04 gives you a working instance in about 90 seconds, SSL config included. On Fedora, you’re either pulling a container, hunting for a COPR repo, or doing a manual PHP + database setup. None of those are impossible, but none of them are 90 seconds either. Snaps get a lot of hate for overhead and confinement weirdness, but for consumer-grade self-hosted apps on a home server where you just want the thing running, the snap path is legitimately easier. Same logic applies to anything shipping only as a .deb — you can convert with alien, but that’s borrowing trouble.

# Ubuntu: Nextcloud up in one command
sudo snap install nextcloud

# Fedora: simplest container path (still works, just more involved)
podman run -d \
  -p 8080:80 \
  -v nextcloud:/var/www/html \
  --name nextcloud \
  nextcloud:28-apache

DNF versus APT is a real difference, but people overstate it as a dealbreaker. On a cold run — no cache, first install of a package — DNF is noticeably slower. Running dnf install htop on a fresh boot with an empty cache takes about 3-4x longer than apt install htop in the same scenario because DNF downloads and processes the full metadata from repos. APT caches aggressively. On a home server where you’re not installing packages constantly, this is a minor annoyance, not a workflow issue. Where it does sting is when you’re doing initial setup or testing a new config — those first few dozen dnf install runs feel sluggish compared to APT. DNF has gotten better with dnf5 (shipping in Fedora 41+), which cuts that metadata overhead significantly.

• Pick Fedora for freshness if your workload is storage-heavy (Btrfs snapshots, ZFS via DKMS), you use Cockpit as your primary management UI, or you need newer systemd features like systemd-nspawn container improvements.
• Pick Ubuntu for ecosystem compatibility if you’re running Nextcloud via snap, need .deb packages from vendor repos (things like Grafana, InfluxDB, or Tailscale all ship .deb first), or you’re relying on PPAs for software not in main.
• Ignore the kernel gap argument unless you’re running brand-new NVMe controllers or GPU drivers — for a home server with commodity hardware from 2021 onward, both kernels will handle it fine.

Long-Term Maintenance: LTS vs Release Cadence

The thing that actually bit me with Fedora on a home server wasn’t a broken package or a config change — it was realizing I had to think about the OS itself every few months. Ubuntu LTS lets you treat the OS like drywall: install it, paint over it, forget it exists. Fedora’s release cadence doesn’t really allow that mindset.

Ubuntu 24.04 LTS gets you 5 years of standard security support from Canonical. If you register for Ubuntu Pro — which is free for personal use on up to 5 machines — that extends to 10 years, and you also get ESM (Extended Security Maintenance) for a much wider set of packages including universe. Enabling it takes about 90 seconds:

# Register your machine with Ubuntu Pro
sudo pro attach YOUR_TOKEN

# Verify ESM is active
sudo pro status

After that, unattended-upgrades handles the security patches and you genuinely do not have to think about OS-level churn for years. I have an Ubuntu 22.04 box running a media stack and a few containers that I SSH into maybe twice a month. The OS has never been the reason I logged in.

Fedora’s support window is roughly 13 months per release, with two releases per year. That math means you’re doing a system upgrade every 6–8 months whether you want to or not. The dnf system-upgrade path is honestly pretty well-engineered — it’s not the harrowing experience it was years ago:

# Upgrade from Fedora 40 to 41
sudo dnf upgrade --refresh
sudo dnf install dnf-plugin-system-upgrade
sudo dnf system-upgrade download --releasever=41
sudo dnf system-upgrade reboot
# system reboots into upgrade mode, completes, reboots again into F41

That process works. I’ve done it across four releases and only hit one real problem (a custom SELinux policy that needed a tweak after). But “works” and “something you want to schedule on a home server” are different things. You still have to pick a weekend, make sure nothing critical is running, verify your services came back clean, and check that your containers or VMs didn’t get surprised by a library version change underneath them. That’s real overhead, even if each individual upgrade takes under an hour.

To make the gap concrete: if you installed Ubuntu 22.04 LTS in April 2022, you’re doing one major upgrade to 24.04 LTS in April 2024, on a tested, documented path that Canonical runs through a formal QA process. In that same window with Fedora, you’d have gone 38 → 39 → 40 → 41 — four upgrades, each one a potential inflection point for your services. For a workstation where you’re actively developing and want fresh toolchains, that cadence is a feature. For a server you want to just run, it’s friction that compounds.

My honest verdict: if you SSH into this box once a month to check on things and otherwise want it to disappear into the background, Ubuntu LTS wins on maintenance overhead alone. The support lifecycle isn’t just a marketing number — it’s the difference between OS maintenance being a scheduled annual review versus a recurring calendar item that follows you around. Fedora is the right call if you need newer kernel features for specific hardware, or if you’re running software that genuinely requires packages that Ubuntu’s repos lag on by 6–12 months. But if neither of those apply to your use case, the LTS model is the obvious choice for a home server you want to trust and forget.

Cockpit: The One Place Fedora Has a Clear Advantage

Fedora Server ships with Cockpit already installed, enabled, and listening. Fresh install, first boot — point your browser at https://your-server-ip:9090 and you’re staring at a real dashboard: CPU/memory graphs, storage layout, network interfaces, systemd journal, service management. No setup steps, no enabling a service, no firewall rules to punch through manually. That out-of-the-box state is the actual differentiator here, not the software itself.

I’ve set up Cockpit on Ubuntu and the gap is real. You run sudo apt install cockpit, which works fine, but then you notice the storage panel feels clunkier — LVM operations and RAID management are noticeably less integrated compared to Fedora where the cockpit-storaged backend hooks in more cleanly. On Fedora Server, the storage tab lets you create LVM volumes, configure RAID, and manage NFS/Samba mounts without touching the terminal. On Ubuntu I kept falling back to CLI for anything non-trivial.

The container integration is where Cockpit on Fedora genuinely earns its keep. Install cockpit-podman and you get container management baked into the same UI:

# Fedora — cockpit is already running, just add the container plugin
sudo dnf install cockpit-podman

# Ubuntu — you need the base first, then the plugin
sudo apt install cockpit cockpit-podman
sudo systemctl enable --now cockpit.socket

For a home server that runs 24/7 and you occasionally need to restart a service at 11pm without opening a terminal, this matters more than you’d think. The systemd journal view inside Cockpit — filterable by unit, searchable, with timestamps — has saved me from firing up journalctl on my phone’s SSH client more times than I want to admit. Fedora’s version of this panel updates in real-time and the integration with SELinux alerts is a nice touch: it’ll surface AVC denials directly in the UI.

That said, the Cockpit advantage collapses pretty fast if your actual workflow is Docker + Portainer or Dockge. Portainer CE gives you a richer container UI than cockpit-podman regardless of which distro you’re on, and Dockge’s compose-file-first approach is something Cockpit doesn’t even attempt to replicate. If your home server is mainly running Docker stacks and you’re already hitting portainer:9000 for container ops, Cockpit becomes just a system metrics panel — useful, but not a deciding factor between the two distros.

Head-to-Head Comparison Table

The table below is where the rubber meets the road. I’ve deliberately avoided “it depends” entries — if you know what you’re running, these rows give you a concrete answer fast.

Feature	Ubuntu 24.04 LTS	Fedora 40
Docker support	apt install docker.io and you’re done. No external repos, no GPG key drama.	Podman ships by default. Docker CE requires adding Docker’s own repo manually. Not a dealbreaker, but it’s friction.
SELinux / AppArmor	AppArmor is active but permissive enough that Samba, NFS, and most homelab services just work out of the box.	SELinux runs in enforcing mode. Samba shares silently fail until you run setsebool -P samba_enable_home_dirs on and friends. Budget an hour the first time.
Support window	5 years standard support. Extended Security Maintenance (ESM) stretches it to 10 years if you register with Ubuntu Pro (free for personal use).	~13 months. After that you’re upgrading or you’re running EOL. There’s no “stay here safely” option.
Kernel freshness	Ships a slightly older kernel by LTS design. Ubuntu 24.04 launched with kernel 6.8. HWE track gets newer kernels mid-cycle.	Fedora 40 shipped with kernel 6.8 at release, tracks upstream closely. The gap with Ubuntu HWE is narrowing — maybe one minor version at most these days.
Web management UI	Cockpit is available but you install it yourself: apt install cockpit. Two minutes of work, but it’s manual.	Cockpit ships pre-installed and enabled. Hit https://yourserver:9090 right after setup with no extra steps.
Snap support	First-class. Snapd runs by default, automatic updates, and Canonical’s whole software distribution strategy leans on it. Love it or hate it, it just works.	Available via third-party repo. Works fine, but Fedora’s ecosystem steers you toward Flatpak and RPM Fusion instead. Nobody’s building Fedora-first Snap packages.
Upgrade path	LTS-to-LTS every two years. Run do-release-upgrade when you’re ready, or just don’t — the system stays supported either way.	dnf system-upgrade every 6–8 months if you want to stay on a supported release. It usually works cleanly, but that cadence is relentless for a server you want to ignore.
Community answers	Stack Overflow, AskUbuntu, and Reddit are saturated with Ubuntu server answers. Whatever weird Jellyfin + reverse proxy issue you hit, someone already solved it on Ubuntu.	Strong Fedora community, but home server edge cases are thinner. You’ll often find the right answer but have to mentally translate it from Ubuntu or CentOS context.

The SELinux row catches most people off guard. I’ve watched developers waste half a day on Samba shares that silently fail because SELinux is blocking access with no obvious error in /var/log/samba/. The fix is usually a one-liner, but you have to know to look for it. On Ubuntu, AppArmor profiles exist but rarely block the services home server folks actually run.

The support window row is the one that actually determines which distro makes sense for a server you want to leave alone. If you’re running a NAS, a Plex box, or a self-hosted Git instance and you check on it maybe once a month, 13 months of support is a genuinely bad fit. Ubuntu 24.04 LTS takes you to 2029 on standard support without touching the machine except for unattended-upgrades. That’s the real argument for Ubuntu on low-maintenance hardware — not any single feature, just the math of how often you want to be forced to interact with the OS.

The Exact Moment Fedora Lost Me for My Main Home Server

I had a Samba share running cleanly for about three weeks — Windows clients on the same LAN, no issues, a mapped drive that just worked. Then I ran sudo dnf upgrade one Tuesday evening, rebooted out of habit, and by Wednesday morning my wife’s laptop couldn’t connect to the share. No error banner, no obvious log spam. Just “Windows cannot access \\homeserver\files” with a generic permission denied. The Samba logs themselves were quiet. /var/log/samba/ showed the connection attempt but nothing that screamed “here’s your problem.” That silence is what cost me 45 minutes.

The upgrade had pulled in a new SELinux policy package — specifically selinux-policy-targeted got a version bump — and that quietly tightened something around Samba’s access to the share directory. To even find the cause I had to run:

# Check AVC denials from the last ~10 minutes
sudo ausearch -m avc -ts recent | grep samba

# Generate a candidate module to allow the denied operations
sudo ausearch -m avc -ts recent | audit2allow -M my_samba_fix
sudo semodule -i my_samba_fix.pp

Once I ran those, the culprit was obvious — the policy was blocking Samba from reading files in a path that didn’t have the right SELinux context. The fix was either sudo chcon -R -t samba_share_t /path/to/share or using restorecon, plus setting samba_export_all_rw boolean with setsebool -P. Totally solvable. But here’s the thing: the dnf upgrade gave me zero warning that a policy change was incoming. There was no “hey, Samba contexts may need reapplying.” The breakage was silent, the diagnosis required knowing SELinux tooling, and nothing in the Samba logs pointed in the right direction. That’s a rough combination for a box you expect to stay boring.

I’ll give Fedora this: working through that forced me to actually understand SELinux beyond “set it to permissive and forget it.” Knowing how to read AVC denials, write a minimal allow module, and think in terms of contexts rather than just file permissions genuinely helped me about two months later when I was debugging a similar issue on a RHEL 9 box at work. So the learning had real value — I’m not dismissing it. But value and timing are different things. On a work machine I’m paid to maintain, yes, invest the 45 minutes and learn something. On a home server at 11pm when someone just wants to play a video file from a shared folder, that’s friction I didn’t sign up for.

Ubuntu with AppArmor isn’t frictionless either — I’ve hit AppArmor denials with LXD containers that were annoying to trace. But AppArmor profiles tend to be application-specific and the error messages are more direct about what’s blocked. More importantly, apt upgrade on Ubuntu LTS doesn’t routinely introduce policy changes that silently break running services between point releases. That predictability is the actual thing I was buying with Ubuntu for home use, and I didn’t fully appreciate it until Fedora taught me what I was trading away.

When Fedora Is Actually the Better Pick

Podman + Quadlets Is Where Fedora Actually Shines

If you’re building container workloads from scratch rather than copy-pasting Docker Compose files from GitHub, Fedora is the better starting point — full stop. Podman is the default container runtime on Fedora, and Quadlets (the systemd-native way to define containers) are first-class citizens, not an afterthought. The thing that caught me off guard the first time I used Quadlets was how clean the mental model is: you write a .container file, drop it in /etc/containers/systemd/, and systemd manages the lifecycle. No daemon. No compose plugin to install. No wondering if the restart policy will survive a reboot.

# /etc/containers/systemd/myapp.container
[Unit]
Description=My App Container
After=network-online.target

[Container]
Image=ghcr.io/myorg/myapp:latest
PublishPort=8080:8080
Volume=/srv/myapp/data:/data:Z  # the :Z matters — SELinux relabeling
Environment=APP_ENV=production
EnvironmentFile=/etc/myapp/secrets.env

[Service]
Restart=always

[Install]
WantedBy=default.target

Run systemctl daemon-reload && systemctl start myapp and you’re done. Compare that to setting up Docker on Ubuntu, installing the compose plugin, writing a systemd unit that wraps docker compose up, and then debugging why the container didn’t start on boot because docker.service wasn’t ready. Fedora’s approach is more work to learn upfront, but the operational model is actually simpler once it clicks. That said — if your workflow is “find a compose file, get it running in 20 minutes,” Ubuntu wins that specific game. Fedora rewards building from intent, not cloning someone else’s setup.

The RHEL Pipeline Argument Is Real for Learning

Fedora is upstream for RHEL. What lands in Fedora today tends to show up in CentOS Stream in 6-12 months and in RHEL a release or two after that. If your home server is also a learning environment and you have any professional interest in enterprise Linux — whether you’re running RHEL at work, studying for the RHCP, or building skills for a job where Red Hat tooling is standard — running Fedora at home keeps you ahead of the curve rather than behind it. You’ll have hands-on time with SELinux policies, firewalld zones, rpm-ostree concepts, and systemd patterns before they’re required knowledge.

Cockpit Is Actually Good and Fedora Treats It Seriously

Cockpit ships with Fedora Server and it gets first-class updates there. I’ve seen people dismiss it as a toy but it handles real work: storage management (LVM, Stratis, RAID), network config, container management via the Podman extension, and system journal browsing with filtering. The Podman integration inside Cockpit lets you start/stop Quadlet-managed containers, pull images, and inspect logs without touching a terminal. For a home server where you might be managing things from a tablet or a borrowed laptop, that’s genuinely useful. Install the storage and container modules if they’re not present:

sudo dnf install cockpit cockpit-storaged cockpit-podman
sudo systemctl enable --now cockpit.socket
# Access at https://your-server-ip:9090

The honest caveat: Cockpit is not Portainer. It doesn’t give you a visual compose editor or a marketplace of pre-built stacks. If you want to manage 20 containers with a nice UI, Portainer Community Edition bolted onto Ubuntu is more polished. Cockpit’s strength is that it’s a system management tool that happens to include containers, not a container platform that happens to include a terminal.

The Upgrade Cadence Will Bite You If You’re Not Ready For It

Fedora releases every six months and each version gets about 13 months of support — so you’re upgrading roughly once a year whether you like it or not. Major version upgrades via dnf system-upgrade work reasonably well most of the time, but “most of the time” is not good enough when you have a Plex library or a home automation setup that needs to stay running. My approach: keep an Ansible playbook or a shell script that can rebuild the server from a fresh Fedora install in under 30 minutes. If you have that, a failed upgrade is an annoyance, not a disaster.

# Fedora major version upgrade — the actual commands
sudo dnf upgrade --refresh
sudo dnf install dnf-plugin-system-upgrade
sudo dnf system-upgrade download --releasever=41
sudo dnf system-upgrade reboot
# System reboots twice, upgrade runs offline — takes 15-45 min depending on package count

The upgrade reliability has improved significantly since Fedora 37-38, but you’ll still occasionally hit a package conflict with a third-party RPM, or find that a kernel module for something like a cheap USB WiFi adapter didn’t survive the transition. Ubuntu LTS gives you five years without touching that problem. Fedora’s model forces you to stay current, which is either a feature or a bug depending on your temperament. If your home server is also where you run critical stuff like home automation or network-wide DNS, build your recovery story before you need it — not after an upgrade goes sideways at 11pm on a Sunday.

When Ubuntu Server Is the Better Pick

The clearest sign Ubuntu is the right call: you Googled a self-hosting guide at midnight, copy-pasted the commands, and everything just worked. That’s not luck — it’s Ubuntu’s intentional design bias toward “works out of the box” over “maximally correct.” For a home server, that bias is often the right one. The entire awesome-selfhosted ecosystem implicitly assumes Ubuntu or Debian. When Immich, Vaultwarden, or Paperless-ngx publish their Docker Compose examples, they test on Ubuntu. When something breaks, the GitHub issue thread will have someone who fixed it on Ubuntu 22.04, not Fedora 39.

If your workload is Docker Compose stacks, Ubuntu is the path of least resistance. The install flow is identical everywhere:

# From the official Docker docs — this is what every guide links to
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER
# Log out, log back in — done

docker compose up -d

On Fedora, you’re using either the official Docker CE repo (which works but lags slightly) or Podman with a compatibility shim. Neither is broken, but when your Compose file uses a depends_on condition that behaves slightly differently under Podman, you’re debugging that at 11pm instead of watching the containers come up clean.

The SELinux situation is the real dealbreaker for file-sharing workloads. Samba and NFS on Fedora require you to either set correct SELinux contexts on every share directory or flip SELinux to permissive mode — which defeats the purpose. Ubuntu ships with AppArmor, which is far more lenient by default and rarely blocks a Samba share. The first time you spend an hour with audit2allow chasing a denied operation on an NFS mount, you’ll understand why Ubuntu users don’t hit that pain point:

# What Fedora users often end up running when Samba silently fails
sudo ausearch -c 'smbd' --raw | audit2allow -M mysamba
sudo semodule -X 300 -i mysamba.pp

# Ubuntu users: smb.conf change + systemctl restart smbd. Done.

Ubuntu’s LTS releases — 22.04 and 24.04 specifically — get five years of security updates. That’s the real pitch for the “set it and forget it” home server. I’ve got a 22.04 box running Jellyfin, Samba, and a WireGuard endpoint that I’ve touched maybe four times in 18 months, all for unattended-upgrades config tweaks. Fedora’s ~13-month lifecycle means you’re doing a dist-upgrade at least once a year, and while dnf system-upgrade has gotten reliable, it’s still an event you have to plan for. On a home server that’s also your NAS, “plan for” often means “do it at 1am hoping nothing breaks your media library mount.”

The Nextcloud Snap is genuinely underrated. I was skeptical — Snaps have a deserved reputation for slow startup and annoying confinement issues — but the Nextcloud snap specifically is one of the better-maintained packages in the ecosystem. It bundles Apache, PHP, Redis, and Nextcloud itself, self-updates, and handles the Let’s Encrypt renewal automatically. For someone who doesn’t want to manage a PHP-FPM + Nginx stack:

sudo snap install nextcloud
sudo nextcloud.manual-install admin yourpassword
sudo nextcloud.enable-https lets-encrypt

That’s a working, HTTPS-terminating Nextcloud instance. The tradeoff is you can’t easily customize the PHP config or swap the web server, but for personal use that rarely matters. Stack Overflow coverage matters more than people admit too — if you’re less experienced with Linux and you paste an error message into a search engine, you want the top three results to be from people running the same distro. Ubuntu’s install base means that’s almost always true. Fedora answers exist, but they’re outnumbered, and the subtle differences in paths, service names, and default configs mean an Ubuntu-specific answer often just works where a generic one doesn’t.

My Actual Verdict After 6 Months Running Both

Six months in, my setup is pretty settled: Ubuntu 24.04 LTS on the main home server, Fedora on a dev VM I rebuild every couple of months without a second thought. That split didn’t come from ideology — it came from what broke and when.

The main box runs Plex, Nextcloud, a handful of Podman containers, and Tailscale. Ubuntu 24.04 LTS hasn’t asked me to think about it since I set it up. Kernel updates apply, packages are where I expect them, nothing has drifted unexpectedly. That’s the entire point. A home server is infrastructure, not a hobby project — I want it running when I’m not looking at it. Fedora 40 running the same workload would have prompted me to intervene at least twice already: once for the glibc bump that broke a containerized service, once for the Podman version jump that changed default network behavior. Both are solvable. Neither is something I want to solve at 11pm on a Tuesday.

The “Ubuntu is for beginners, Fedora is for pros” framing is genuinely backwards. Choosing boring, predictable infrastructure is a deliberate, experienced decision. The people I know who run the most reliable homelabs aren’t chasing the newest kernel — they’re on LTS releases with long-tested package versions and they sleep well at night. Ubuntu 24.04 gets security backports for five years. That’s a feature, not a cop-out. The Fedora crowd sometimes conflates “closer to upstream” with “more serious,” but if your server’s job is to serve files, stream video, and sync calendars, staying close to upstream is irrelevant friction.

Where Fedora genuinely earns its spot: my dev VM is the place I want to see Podman Quadlet improvements as they land, watch how systemd integration is evolving, and get comfortable with patterns that’ll show up in RHEL 10. If you’re consulting, contracting, or just want to stay sharp on where enterprise Linux is heading, a Fedora VM you can nuke and rebuild is a cheap way to do that. I also use it as a scratchpad for Ansible playbooks before they touch the production box — Fedora’s faster package iteration means I catch compatibility issues earlier. Speaking of Ansible, if you’re automating your homelab setup, the Best AI Coding Tools in 2026 are surprisingly capable at generating Podman Quadlet unit files and boilerplate playbooks — I’ve been using a couple of them to stub out roles I then actually review and edit, which saves the tedious parts without handing over control entirely.

My actual recommendation: if you’re standing up a home server and you want to ask “which one is better,” just use Ubuntu 24.04 LTS. Not because it’s easier, but because the question you’ll be asking six months from now should be “how do I add more storage” — not “why did my Nextcloud container stop starting after last week’s update.” Reach for Fedora when you have a specific reason to, not because someone told you it’s what serious Linux users run.

---

---