Hands-on Lab·CompTIA Linux+
A service, an account, and the permission between them
Domain 2 pairs services with accounts, and this guide treats them as one subject. It creates a system account that cannot log in, writes a unit that runs as that account, then points the unit at a directory it has no right to - and reads the failure back out of the journal before fixing the permission rather than the unit.
Services and Users Guide 5 of 28 Intermediate
- PlatformsUbuntu 26.04 LTS + AlmaLinux 10.2
- Mandatory access controlAppArmor on Ubuntu, SELinux enforcing on Alma
- Firewallufw / nftables 1.1.6
- TimeAbout 24 min
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| LPLUS-A01 | 192.168.0.73 | Ubuntu 26.04 LTS | Debian-family host - apt, ufw, netplan, AppArmor | 2 Core | 4 GB | 50 GB |
| LPLUS-B01 | 192.168.0.74 | AlmaLinux 10.2 | RPM-family host - dnf, firewalld, NetworkManager, SELinux | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when a service will not start and the status output only says it failed. This matters because a unit running as its own user fails on permissions far more often than on configuration, and the journal names the file while systemctl status does not.
- creating a system account with no login, and seeing what
sudo -ustill does with it - giving it one directory it owns and one it does not
- writing a unit that runs as that account, verifying it, and enabling it
- breaking it on a permission and reading the real cause out of the journal
- fixing it by group rather than by ownership, and comparing the account on both families
Before you start
- a-disk-a-filesystem-and-a-mount-that-survives
-
An account that exists to run something, not to log in
-
A directory it owns, and one it does not
-
A unit that runs as that account
-
What the service actually ran as
-
The same unit, pointed at the directory it cannot write
-
Fixing it at the layer that is broken
-
The same account on the RPM family
-
Putting both machines back