---

   homectl    ( 1 )

---

Описание (Description)

homectl may be used to create, remove, change or inspect a user's home directory. It's primarily a command interfacing with systemd-homed.service(8) which manages home directories of users.

Home directories managed by systemd-homed.service are self-contained, and thus include the user's full metadata record in the home's data storage itself, making them easy to migrate between machines. In particular, a home directory describes a matching user record, and every user record managed by systemd-homed.service also implies existence and encapsulation of a home directory. The user account and home directory become the same concept.

The following backing storage mechanisms are supported:

• An individual LUKS2 encrypted loopback file for a user, stored in /home/*.home. At login the file system contained in this files is mounted, after the LUKS2 encrypted volume has been attached. The user's password is identical to the encryption passphrase of the LUKS2 volume. Access to data without preceding user authentication is thus not possible, even for the system administrator. This storage mechanism provides the strongest data security and is thus recommended.

• Similar, but the LUKS2 encrypted file system is located on regular block device, such as an USB storage stick. In this mode home directories and all data they include are nicely migratable between machines, simply by plugging the USB stick into different systems at different times.

• An encrypted directory using "fscrypt" on file systems that support it (at the moment this is primarily "ext4"), located in /home/*.homedir. This mechanism also provides encryption, but substantially weaker than LUKS2, as most file system metadata is unprotected. Moreover it currently does not support changing user passwords once the home directory has been created.

• A "btrfs" subvolume for each user, also located in /home/*.homedir. This provides no encryption, but good quota support.

• A regular directory for each user, also located in /home/*.homedir. This provides no encryption, but is a suitable fallback available on all machines, even where LUKS2, "fscrypt" or "btrfs" support is not available.

• An individual Windows file share (CIFS) for each user.

Note that systemd-homed.service and homectl will not manage "classic" UNIX user accounts as created with useradd(8) or similar tools. In particular, this functionality is not suitable for managing system users (i.e. users with a UID below 1000) but is exclusive to regular ("human") users.

Note that users/home directories managed via systemd-homed.service do not show up in /etc/passwd and similar files, they are synthesized via glibc NSS during runtime. They are thus resolvable and may be enumerated via the getent(1) tool.

This tool interfaces directly with systemd-homed.service, and may execute specific commands on the home directories it manages. Since every home directory managed that way also defines a JSON user and group record these home directories may also be inspected and enumerated via userdbctl(1).

Home directories managed by systemd-homed.service are usually in one of two states, or in a transition state between them: when "active" they are unlocked and mounted, and thus accessible to the system and its programs; when "inactive" they are not mounted and thus not accessible. Activation happens automatically at login of the user and usually can only complete after a password (or other authentication token) has been supplied. Deactivation happens after the user fully logged out. A home directory remains active as long as the user is logged in at least once, i.e. has at least one login session. When the user logs in a second time simultaneously the home directory remains active. It is deactivated only after the last of the user's sessions ends.