systemd-homed 移行で実現するユーザーホーム可搬化｜既存環境との差分と注意点

ユーザーのホームディレクトリを暗号化したまま別マシンへ持ち運ぶ、あるいは USB ストレージからそのままマウントしてログインする——systemd-homed はこの要求に応えるために設計されたサブシステムです。2020年の systemd 245 で導入されて以降、2026年時点では主要ディストリビューションの多くが標準パッケージとして収録しており、本番投入の選択肢として現実的な段階に入っています。本記事では「既存の伝統的ユーザーから homed 管理ユーザーへ移行する」運用シナリオを軸に、事前確認・手順・検証・切り戻しまでを順を追って説明します。

systemd-homed が解決する課題とアーキテクチャの概要

従来の Linux ユーザー管理では、ユーザー情報は /etc/passwd・/etc/shadow、ホームディレクトリは /home/username/ にそれぞれ分散して存在します。別マシンへ移行する際は UID の衝突調整・シャドウファイルの編集・ホームのアーカイブ転送という手作業が必要で、暗号化を組み合わせると更に工程が増えます。

systemd-homed はこの問題を、ホームディレクトリをひとつの「持ち運び可能なユニット」として扱うことで解決します。具体的には次の3形式でホームを格納できます。

• luks（既定）: LUKS2 で暗号化したループイメージファイル（/home/username.home）。ログイン時にカーネルのデバイスマッパーでマウント、ログアウト時に自動ロック。
• directory: /home/username/ を通常ディレクトリとして管理。暗号化なし・移行コスト低。
• subvolume: Btrfs 環境でサブボリュームとして作成。スナップショット活用が容易。

ユーザー情報は JSON レコードとしてホームイメージ内に格納されるため、/etc/passwd に依存しません。異なるマシンへイメージファイルをコピーし homectl adopt するだけで同じユーザーとして認識されます。UID 衝突の概念も変わり、マシン固有の UID は起動時に動的割り当てされます。

事前準備と現行環境の確認

移行作業を始める前に、対象環境が要件を満たしているかを確認します。

systemd バージョンと依存パッケージの確認

systemctl --version       # 245 以上であること
systemctl status systemd-homed.service

systemd-homed.service が存在しない場合は、ディストリのパッケージから systemd-homed（Debian/Ubuntu 系）または systemd（Fedora/RHEL 系、homed は本体に同梱）をインストールします。LUKS 形式を使う場合は cryptsetup も必要です。

# Debian/Ubuntu
sudo apt install systemd-homed libpam-systemd

# Fedora / RHEL 9+
sudo dnf install systemd   # homed は同梱済み

PAM の設定確認

homed ユーザーのログインには PAM モジュール pam_systemd_home.so が必要です。/etc/pam.d/common-auth（Debian 系）または /etc/pam.d/system-auth（Fedora/RHEL 系）に以下が含まれているかを確認します。

auth       sufficient   pam_systemd_home.so
account    sufficient   pam_systemd_home.so
session    optional     pam_systemd_home.so
password   sufficient   pam_systemd_home.so

Debian/Ubuntu では pam-auth-update を実行すると対話的に有効化できます。Fedora 系では authselect を使います。設定ミスがあるとログイン不能になるため、作業前に root セッションを別端末で必ず維持しておきます。

homectl による homed ユーザーの作成と既存データ移行

既存の伝統的ユーザー alice を homed 管理へ移行する想定例として説明します。

homed サービスの起動と有効化

sudo systemctl enable --now systemd-homed.service

homed ユーザーの新規作成

既存ユーザーを直接変換するコマンドは存在しないため、新しい homed ユーザーを作成してデータを移行するという手順を踏みます。まず作業用の移行先ユーザーを作成します。

# LUKS 暗号化形式（既定）で作成
sudo homectl create alice-new \
  --real-name="Alice" \
  --storage=luks \
  --disk-size=20G \
  --shell=/bin/bash

--storage=directory を指定すれば暗号化なしのディレクトリ形式になります。--disk-size は LUKS イメージのサイズ上限で、後から homectl resize で変更できます。

既存ホームからのデータコピー

homed ユーザーのホームはログイン中のみマウントされます。一時的に手動でアクティベートしてからコピーします。

# 一時アクティベート（パスワードを求められる）
sudo homectl activate alice-new

# 旧ホームから新ホームへ rsync
sudo rsync -a --exclude='.cache' \
  /home/alice/ \
  /home/alice-new/

# オーナーを新ユーザーに付け直す
sudo homectl inspect alice-new | grep UID
# 表示された UID を使って chown（homed は動的 UID のため確認が必要）
sudo chown -R $(id -u alice-new): /home/alice-new/

コピー後、既存ユーザー alice を無効化し（sudo usermod -L alice）、運用確認が取れてから削除します。名前を元に合わせたい場合は alice-new での検証後に旧ユーザーを削除してから homectl rename alice-new alice で改名します。

別マシンへのホーム持ち運び（可搬化の核心）

可搬化の実体は LUKS イメージファイル /home/alice.home のコピーです。

# ソースマシンでデアクティベート後にコピー
sudo homectl deactivate alice
scp /home/alice.home user@target-host:/home/

# ターゲットマシンで採用
sudo homectl adopt /home/alice.home

homectl adopt はイメージ内の JSON レコードを読み込み、ターゲットマシンの homed データベースに登録します。UID はターゲット側で空きを探して動的に割り当てられるため、UID 衝突が原因のファイル権限問題は発生しません。

動作検証と homed ユーザーの状態確認

移行後は以下のコマンドで状態を確認します。

# homed が管理するユーザー一覧
homectl list

# 特定ユーザーの詳細（UID・ストレージ形式・ディスク使用量など）
homectl inspect alice

# 統合ユーザーデータベース全体の確認（homed + NSS の両方が見える）
userdbctl

homectl list の STATUS 列が active（ログイン中）または inactive（ロック済み）と表示されれば正常です。absent はイメージファイルが見つからない状態を示します。

ログインテストは SSH か仮想コンソールで行い、ログイン直後に df -h ~ でホームが別デバイスとしてマウントされていることを確認します。LUKS 形式では /dev/mapper/home-alice のようなデバイスが現れます。ログアウト後は lsblk からそのデバイスが消え、ホームがロック状態に戻っていることを確認できます。

切り戻し手順と運用上の注意点

切り戻しの基本方針

切り戻しが必要な場合、homed ユーザーを従来ユーザーに戻す手順は次のとおりです。

# 1. homed ユーザーのホームを一時アクティベートしてデータを退避
sudo homectl activate alice
sudo rsync -a /home/alice/ /home/alice-legacy/

# 2. homed ユーザーを削除（イメージファイルも削除される）
sudo homectl remove alice

# 3. 従来ユーザーを再作成
sudo useradd -m -d /home/alice alice
sudo rsync -a /home/alice-legacy/ /home/alice/
sudo chown -R alice: /home/alice/

# 4. PAM から pam_systemd_home.so を外す（または sufficient → optional に格下げ）

よくある運用上のつまずき

• バックグラウンドサービスとの非互換: homed ユーザーのホームはセッション中のみマウントされます。cron・systemd ユーザーユニット・Docker コンテナがユーザーのホームパスを読む構成では、ログアウト後にアクセスエラーが発生します。バッチ処理用アカウントには homed は向いていません。
• NFS・LDAP 環境との併用: homed は /etc/nsswitch.conf の nss-systemd 経由で名前解決します。LDAP や NIS と混在させる場合、userdbctl の出力と getent passwd の出力が異なるケースがあるため、認証フローの検証が必要です。
• sudo・su の挙動: sudo は PAM を通じて動作するため基本的に問題ありませんが、/etc/sudoers にユーザー名で直接記述している場合、homed が動的割り当てする UID によっては意図しない挙動を招くことがあります。グループベースの sudoers 設定を推奨します。
• ディスクサイズの見積もり: LUKS イメージのサイズ上限を超えると書き込みエラーになります。homectl resize alice 40G でオンライン拡張できますが、ループバックデバイスのリサイズ処理が発生するため高負荷時は避けます。

2026年時点の対応ディストリビューションと環境差分

2026年10月時点の主要ディストリビューションにおける systemd-homed の対応状況は以下のとおりです。

Ubuntu 24.04 LTS（Noble Numbat）/ 25.04

systemd 255 系が搭載されており、systemd-homed パッケージは標準リポジトリに収録されています。PAM 設定は pam-auth-update が自動管理するため、sudo pam-auth-update --enable systemd-home で有効化できます。GDM（GNOME デスクトップ）との統合はおおむね安定していますが、LightDM を使うデスクトップ環境では PAM セッション処理の順序に依存した問題が報告されているため、サーバー用途での検証を推奨します。

Fedora 41 / RHEL 10

Fedora は systemd-homed の開発元と近い立場にあり、最も早く新機能が取り込まれるディストリです。Fedora 41 は systemd 257 系を採用しており、authselect select sssd with-systemd-homed で PAM 統合を行います。RHEL 10 は RHEL 9 での「テクノロジープレビュー」から正式サポートへ昇格する方向性が示されており、2026年時点では本番利用のドキュメントが Red Hat の公式ナレッジベースに掲載されています。

Debian 13（Trixie）

Debian 13 では systemd 256 系が採用されています。systemd-homed パッケージが main に昇格しており、インストール後の PAM 統合は Ubuntu と同様に pam-auth-update で管理されます。Debian の保守的なポリシー上、デフォルトでは有効化されていないため、意図的に設定を追加する必要があります。

共通の現行仕様変更点（systemd 255 以降）

• systemd 256 から homectl passwd によるパスワード変更が FIDO2 ハードウェアキーに対応。Yubikey を認証要素として登録できます。
• homectl create の --auto-resize-mode= オプションが追加され、ホームの空き領域が少なくなった際の自動拡張ポリシーを設定できるようになっています。
• systemd-homed が管理するユーザーは userdbctl users で一覧表示できますが、getent passwd でも表示するには /etc/nsswitch.conf に systemd エントリが含まれている必要があります。ディストリによって初期設定が異なるため、移行直後に確認する習慣をつけておくと無用な混乱を避けられます。

systemd-homed はまだすべての運用パターンをカバーする成熟度には至っていませんが、個人ワークステーションや開発環境のポータビリティ向上、あるいはエッジデバイスへのユーザー持ち込みといったシナリオでは実用的な選択肢になっています。導入前に対象ワークロードが「セッション中のみホームにアクセスする」モデルと一致するかを確認することが、安定運用への第一歩です。