ShieldedBytes

The “Failed to mount /home” error and a missing UUID

If you boot into a black screen and the kernel spits out

Failed to mount /home

you’re almost certainly dealing with a stale or wrong UUID in /etc/fstab.
Systemd uses that UUID to locate the block device, and if it can’t find a match, the mount unit dies and the user session never starts.

1. Identify the missing UUID

# Show all block devices with their UUIDs
sudo blkid

# Or a tree view
sudo lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,UUID

Look for the entry that should be /home. If the UUID printed here differs from the one in fstab, that’s your mismatch.
If the device itself is gone (say you unplugged an SSD), you’ll have to rebuild the partition or point /home elsewhere.

Why /tmp is a problem

/tmp is the classic “dump‑ground” for most Linux programs.
Because it’s world‑writable, a non‑root user can drop a rogue binary, swap out a shared library, or trick a set‑uid helper into loading code from there.
In 2025 a handful of local privilege‑elevation bugs (e.g., CVE‑2025‑1234) took advantage of that writable surface to inject payloads into privileged processes.
The fix? Make /tmp read‑only for everyone but root.

Why Separate Keys for Each Account Matter

When a single server hosts several user accounts—think a web developer, a database admin, and a system operator—sharing the same SSH key across those accounts is tempting but risky. A compromised key gives an attacker full access to every account it’s authorized for. Keeping distinct key pairs per account limits blast radius, simplifies revocation, and lets you apply per‑user restrictions in authorized_keys.

Generating and Distributing Keys

# On the client, generate a key for the web dev
ssh-keygen -t ed25519 -f ~/.ssh/webdev_id_ed25519 -C "[email protected]"

# For the DB admin
ssh-keygen -t ed25519 -f ~/.ssh/dbadmin_id_ed25519 -C "[email protected]"

I always pick ed25519 because it’s faster and still strong. Store the private keys with chmod 600. Push the public key to the server for each user:

Introduction to Container Logging

I’ve seen container logging become a major headache for many of us managing containerized applications. With containers being adopted more widely in production environments, the need for efficient and scalable logging solutions has become increasingly important. Tools like Loki and systemd Journal have significantly changed the landscape in recent years. In this article, I’ll share how to use Loki and systemd Journal to tame those unruly container logs.

Introduction to resolvectl

I’ve been using resolvectl for a while now, and I’ve found it to be a powerful tool for managing DNS resolution on Linux systems that use systemd. It provides a flexible and efficient way to configure DNS settings, including DNS over TLS (DoT) and DNS over HTTPS (DoH). As of 2026, many Linux distributions, including Arch Linux and Ubuntu, have adopted systemd-resolved as the default DNS resolver. This is a good thing, in my opinion, as it simplifies DNS management and provides better security features out of the box.

Introduction to Journalctl Filters

I’ve seen log management become a major headache when working with Linux systems - it’s crucial for troubleshooting, security auditing, and system maintenance. That’s where journalctl comes in, a powerful tool provided by systemd for managing and analyzing log data. But let’s be honest, dealing with the sheer volume of log entries can be overwhelming. This article will show you how to tame that “log noise” using journalctl’s built-in filters and priorities.

Introduction to Background Jobs

I’ve seen this go wrong when you’re running commands or scripts in the background - if not managed properly, these background jobs can consume system resources, leading to performance issues or even security risks. That’s why I’m a big fan of using nohup and ionice to tame runaway background jobs. In this article, I’ll walk you through some practical examples and security considerations for using these tools.

Introduction to Log Noise

I’ve seen this go wrong when log noise gets out of hand - it’s like trying to find a needle in a haystack. With the complexity of Linux systems increasing, log noise has become a significant problem for sysadmins, self-hosters, and developers. Luckily, we have logrotate to help tackle this issue. It’s a standard tool on most Linux distributions, including Debian, Arch Linux, and Red Hat.

Managing Shared Directories in Linux

I’ve seen permission management become a real headache when working with shared directories in Linux. Multiple users and groups need to access the same files, but with different levels of permission. To tame these shared directories, you can use setgid, sticky bits, and Access Control Lists (ACLs).

Understanding setgid

The setgid bit is a special permission that allows a directory to inherit the group ownership of its parent directory. This is useful for shared directories where multiple users need to collaborate on files. I usually start with setting the setgid bit on a directory using the following command:

Introduction to Docker Volumes

I’ve seen this go wrong when managing Docker on a small Linux server: volumes can become a challenge. Docker volumes are directories that are shared between the host system and containers, allowing for persistent data storage. If not properly managed, they can lead to disk space issues and security risks. The real trick is to stay on top of volume management to avoid these problems.

Understanding Docker Volumes

To create a new volume, you can use the docker volume command. For example, to create a new volume named my-volume, you can use the following command: