systemd-homed: Portable Encrypted Home Directories

Your Home Directory Has Been Living a Lie

Here’s how Linux user accounts have worked since forever: /etc/passwd holds your username and UID, /etc/shadow holds a hashed password, and your home directory sits at /home/yourname owned by root’s decision to give you permission to be there. It works fine until it doesn’t.

Take that laptop to a different machine? Your UID might collide with someone else’s. Drop it off for repair? Whoever boots it can mount your unencrypted home. Log into a shared workstation? Your dotfiles and SSH keys live on that machine indefinitely, long after you’ve gone.

systemd-homed is the answer to all of that, and honestly it’s one of the more interesting things to come out of the systemd project in years. The idea: your home directory isn’t a folder on the machine anymore, it’s a self-contained LUKS-encrypted blob that travels with you and gets unlocked at login.

What Actually Changes With homed

Classic Linux splits your identity across at least three places: the user database (/etc/passwd), the auth system (/etc/shadow or PAM/LDAP), and the filesystem (/home/you). These are all separate, loosely coupled, and the filesystem has no idea who you are, it just knows UID numbers.

homed collapses all of this into one object. Your home directory is a LUKS2-encrypted image file stored at /home/yourname.home (the .home suffix is for LUKS storage; .homedir is what you’d see for the plain directory backend). Inside that image lives a JSON record, the user record, that contains your username, UID, group memberships, password hash, enrolled hardware tokens, and any other metadata about you. The image IS the user. Mount it anywhere on any machine and the system knows everything it needs to know about you.

When you log in:

1. systemd-homed finds your .home image
2. Authenticates you (password, FIDO2 key, PKCS#11 token, TPM: whatever you enrolled)
3. Unlocks and mounts the LUKS volume at /home/yourname
4. Hands off to PAM, which proceeds normally
5. On logout, the volume unmounts and the LUKS container locks

Your data is encrypted at rest any time you’re not actively logged in. Not “encrypted if someone remembers to enable full-disk encryption”, always encrypted, owned by the user record inside the blob itself.

Getting Started: homectl

homectl is your interface to all of this. Let’s walk through the basics.

Creating a homed User

sudo homectl create alice \
  --storage=luks \
  --disk-size=20G \
  --real-name="Alice Example" \
  --member-of=wheel

This creates /home/alice.home, a 20 GB LUKS2 image. The --storage=luks flag is what makes it portable and encrypted. Other storage backends exist (directory, subvolume, fscrypt) but LUKS is the one you want for portability and full encryption.

You’ll be prompted to set a password interactively. After that:

homectl list

NAME  UID   GID   STATE    REALNAME      HOME
alice 60001 60001 inactive Alice Example /home/alice

The UID is dynamically assigned from the range 60001 to 65519 when the user logs in, not fixed at creation time. This is the “dynamic UID” thing that breaks some software (more on that later).

Inspecting a User Record

homectl inspect alice

This dumps the full JSON user record. You’ll see fields like privileged (contains the hashed password), signature (cryptographic signature over the record), disk size, last login time, and enrolled authentication methods. It’s a lot more structured than /etc/passwd ever was.

Changing a Password

homectl passwd alice

Old password, new password, done. The hash lives inside the encrypted image, so this change is baked into the blob itself, not in /etc/shadow on the host.

Enrolling a FIDO2 Key

This is where it gets genuinely useful. Got a YubiKey?

homectl authenticate alice        # unlock the record first
homectl enroll-fido2 alice

Plug in your key, tap it when prompted. Now alice can log in by inserting the FIDO2 key instead of (or in addition to) a password. The credential is stored in the user record inside the LUKS image.

Resizing on the Fly

LUKS2 supports online resizing, and homed uses it:

homectl resize alice 40G

While alice is logged in, the LUKS container and the filesystem inside it both grow to 40 GB. No unmounting, no fumbling with resize2fs by hand.

Locking and Deactivating

homectl deactivate alice   # unmounts and locks the LUKS volume
homectl activate alice     # prompts for auth and mounts it

You can also lock all home dirs at once, useful before suspend:

homectl lock-all

Portability in Practice

Here’s the actual workflow that makes this useful: your home dir lives on a USB drive or a network share, and you carry it between machines.

Copy the blob:

cp /home/alice.home /media/usb/alice.home

On another machine with systemd-homed.service enabled, the simplest path is to drop the .home file into /home/, homed scans that directory and picks it up automatically:

sudo cp /media/usb/alice.home /home/alice.home
homectl activate alice

If you’d rather keep the image somewhere else and just register it for login, recent systemd (v258+) added homectl import-blob /path/to/alice.home to do exactly that without moving the file.

Enter your password (or tap your FIDO2 key), and you’re logged in on a machine that’s never heard of you. Your dotfiles, SSH keys, shell history, GPG keyring, all of it came with you, and it was encrypted the entire time it was sitting on that USB drive.

This is the threat model homed is actually designed for: shared workstations, lent laptops, consultant setups where you work on client hardware you don’t control. Classic full-disk encryption protects data when the machine is off, homed protects your data from other users on the same machine while you’re both logged in.

Comparing to the Alternatives

Full-disk LUKS, Protects against “someone walks off with your laptop.” Doesn’t help on shared machines or when you want to move your identity between systems. These aren’t competing, homed + LUKS on the underlying disk is a reasonable combination.

eCryptFS, The old encrypted home story on Ubuntu. Deprecated, uses the kernel keyring in a fragile way, no portability story, no hardware token support. Leave it in 2018 where it belongs.

Encrypted home in the stock installer, Most distros (Fedora, Ubuntu) offer “encrypt home directory” at install time. This is usually eCryptFS or a thin wrapper around it. No user record portability, no FIDO2. Fine for basic privacy, not for what homed is trying to do.

LDAP/Active Directory, Solves the shared workstation authentication problem, not the data portability or at-rest encryption problem. Requires infrastructure. homed works offline with no server dependency, which is the whole point.

The Caveats You Should Know Before You Dive In

Distro support is uneven. Fedora has had homed for a while and it’s pretty solid. Ubuntu and Debian are more conservative, you can install and run it, but it’s not the default, and some distro-specific tooling (like the graphical user manager) doesn’t know it exists. Arch users, predictably, have no trouble with it. If you’re on a corporate machine running RHEL 8, don’t bother.

Dynamic UIDs break some software. Because UIDs are assigned at login time from a range, a file created by alice on machine A might have a different UID than the same user on machine B if the ranges collide or the assignment differs. Most modern software is fine with this, but older stuff that hardcodes UIDs, some cron setups, legacy print spoolers, certain NFS configurations, will have a bad time.

Containers and Kubernetes don’t care about this. homed is a workstation/laptop feature. If you’re thinking about running this on Kubernetes nodes or in Docker containers, you’re solving the wrong problem. That world has its own identity primitives. homed is for humans sitting at machines.

Some PAM stacks need manual wiring. If you’re on a distro where pam_systemd_home.so isn’t already in the PAM stack, you’ll need to add it. Get it wrong and you’ll be recovering from a tty. Test in a VM first. Your future self at 2 AM will thank you.

The image file size is pre-allocated. That 20 GB image is 20 GB on disk even if you only use 2 GB of actual files. Sparse images help but the tooling doesn’t always handle them perfectly. Plan your sizes thoughtfully.

Enabling homed on an Existing System

If you’re on a systemd-based distro and want to experiment:

sudo systemctl enable --now systemd-homed.service

Check it’s running:

systemctl status systemd-homed.service

Make sure pam_systemd_home.so is in your PAM auth stack. On Fedora this is already set up. On Debian/Ubuntu, check /etc/pam.d/common-auth and /etc/pam.d/common-session, you may need to add it manually.

auth    sufficient    pam_systemd_home.so

Then create a test user as shown above and try logging in as that user in a second terminal before committing to anything.

The Bottom Line

systemd-homed is solving a real problem that’s been swept under the rug for decades: Linux user identity is scattered across files that don’t travel with you and data that isn’t encrypted unless someone set up full-disk encryption at install time.

Is it perfect? No. The ecosystem support is still catching up, dynamic UIDs have rough edges, and if you live in a container-first world this is entirely irrelevant to your daily life. But for the use case it’s designed for, portable encrypted identity on real hardware, it works, and it’s significantly more elegant than duct-taping eCryptFS to an LDAP server and hoping for the best.

If you’re setting up shared workstations, regularly work on machines you don’t own, or just want your home directory to be encrypted without having to think about it, homed is worth the setup time. Carry your house with you. Lock it when you leave.

Related Reading

• Tang & Clevis: LUKS Auto-Unlock Without a Typed Passphrase
• YubiKey + age: Hardware-Backed Encryption Without GPG
• Advanced UFW Techniques: Enhancing Firewall Security
• AppArmor vs SELinux: Mandatory Access Control Without the Existential Dread
• Auditd & Audit Logging: Know Exactly Who Touched What on Your Server