ShieldedBytes

A One‑Command Escape from Emergency Mode

When a typo in /etc/fstab stops the root filesystem from mounting, Ubuntu 24.04 drops straight into emergency mode. You get a read‑only root shell, but that’s not useful because you can’t edit the offending line—root is already mounted read‑only. The usual fix is to reboot, pull out a live USB, and patch the file from there.
There’s a much quicker way that keeps you on the same machine, preserves the state, and lets you fix the problem in place.

ACLs for log‑only access

When you need a user to read system logs but you don’t want to give them sudo or pull them into a privileged group, POSIX ACLs are the cleanest way to do it.
They let you hand out read rights on a per‑file or per‑directory basis, and you can set defaults so that every new file inherits the same restrictions.

A backup account that pulls logs to an off‑site archive but never touches the live system is the classic case. ACLs keep the principle of least privilege intact while still letting the job run unattended.

Rootless Podman on a Raspberry Pi – Solving the “Cannot Bind Mount /home/user/data” Permission Issue
The Raspberry Pi has become a favorite platform for home‑lab enthusiasts, and Podman’s rootless mode lets you run containers without granting the container process full system privileges.
On a Pi running Raspberry OS Bookworm (Debian 12), a common stumbling block is the error

Error: cannot bind mount /home/user/data: permission denied

when you try to persist data with -v /home/user/data:/data.
Below is a step‑by‑step guide that explains why the error happens, how to fix it, and what security trade‑offs you should be aware of.

Why you need it

Syslog is the first place you look when something goes wrong. In a busy server or a home lab, the same message can appear thousands of times a day. Knowing which lines dominate the log helps spot misconfigurations, repeated failures, or malicious activity that repeats silently. A quick frequency count is a low‑overhead sanity check that can turn a noisy log into a focused list of suspects.

Why Docker logs can eat a NAS

A home NAS is usually a single‑disk or a small RAID array.
When you run several containers—media servers, databases, CI runners—each one writes a JSON log file under /var/lib/docker/containers/<id>/<id>-json.log.
If you leave the default json-file driver untouched, those files grow indefinitely.
On a 1 TB NAS, a handful of containers can fill the drive in weeks, forcing you to delete data or upgrade hardware.

Why firewalld blocks HTTP even when port 80 is open

I’ve run Fedora, CentOS, and RHEL for the past two decades, and firewalld is the default manager on those distros. It hides the nitty‑gritty nftables/iptables behind zones, services, and ports. That abstraction is handy, but it can also mask a subtle mismatch that ends up dropping HTTP traffic even though you’ve “opened” port 80. The culprit is almost always a services vs. ports trap.

Why ACLs instead of changing ownership?

When a web server runs as www-data and the dev squad needs to touch files in /var/www/html, the quick fix is usually chgrp the directory and slap a write bit on the group. That swaps the group ownership, which can trip up services that expect the original group or automated deploy scripts that hard‑code the owner. ACLs let you hand out the right permissions without touching the classic ownership columns.

Why a single auditd rule is better than scattered syslog entries

When you run sudo, you’re stepping into privileged territory. Most distros ship a sudo wrapper that dumps a message into syslog. That message can be noisy, hard to sift through, and it doesn’t survive a clean‑up or a reboot. A dedicated auditd rule, on the other hand, captures every sudo invocation in a structured, tamper‑evident format. Couple that with a tiny logrotate config, and you get a reliable audit trail that sticks around long after the machine has been rebooted or the disk wiped.

Why Inode Exhaustion Happens

On a busy server you’ll often see df still showing plenty of space, but df -i screaming 100 % inode usage on a mount like /usr. The kernel will happily refuse to create any more files, even though there’s room on disk. The culprit is usually a deluge of tiny files—think logs, temp data, or a mis‑configured service that never cleans up.

Spotting the Problem Quickly

# Space vs. inodes
df -h /usr
df -i /usr

If the first command reports 20 GB free but the second is 100 % used, you’ve hit an inode shortage. Now find the directory that’s eating them.

A 1‑GB VPS that dies in 15 minutes: the /tmp overflow problem

When a 1‑GB VPS runs a handful of services that write temporary files—apt‑get, pip, Docker, or even a simple web server—the /tmp directory can fill up faster than you think. Once the filesystem is full, many processes abort, the kernel starts killing tasks, and the machine can become unresponsive. The fix is surprisingly simple: mount /tmp as a tmpfs so it lives in RAM instead of on the disk.