リモート マシンのディレクトリを にマウントしたいと思います/home/stew/shared
。 をリモート マシンにインストールしsshfs
て使用した後ssh-copy-id
、次の操作を実行できます。
stew@stewbian:~$ sshfs [email protected]:/path/to/remote-dir ~/shared
そしてアンマウントする
stew@stewbian:~$ umount ~/shared
または
stew@stewbian:~$ fusermount -u ~/shared
stew
うまく動作しますが、ログイン時にこれを自動的にマウントし、stew
ログアウト時にアンマウントしたいと思います。 1 つの有効なオプションは.service
、ユーザー バスで systemd を使用することです。
# ~/.config/systemd/user/shared.service
[Unit]
Description=Mount ~/shared
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=sshfs %[email protected]:/path/to/remote-dir %h/shared
ExecStop=umount %h/shared
[Install]
WantedBy=default.target
systemctl --user {start,stop} shared.service
.mount
も素晴らしいです! しかし、ユニットはもっと堅牢になるのだろうかと思います。
次のようなマウントユニットを使用してみました:
# ~/.config/systemd/user/home-stew-shared.mount
[Unit]
Description=~/shared
[Mount]
What=%[email protected]:/path/to/remote-dir
Where=%h/shared
Type=fuse.sshfs
[Install]
WantedBy=default.target
このマウント ユニットを起動すると正常に動作しますが、停止すると次の問題が発生します。
$ systemctl --user status home-stew-shared.mount
● home-stew-shared.mount - ~/shared
Loaded: loaded (/home/stew/.config/systemd/user/home-stew-shared.mount; static)
Active: active (mounted) (Result: exit-code) since Mon 2021-05-24 16:49:40 CEST; 6min ago
...
May 24 16:49:40 stewbian systemd[1046]: Unmounting ~/shared...
May 24 16:49:40 stewbian umount[22256]: umount: /home/stew/shared: must be superuser to unmount.
May 24 16:49:40 stewbian systemd[1046]: home-stew-shared.mount: Mount process exited, code=exited, status=32/n/a
May 24 16:49:40 stewbian systemd[1046]: Failed unmounting ~/shared.
$ umount ~/shared
ディレクトリをアンマウントしてユニットを失敗させることができます。
質問:
*.mount
ユニットよりもユニットを優先する理由はありますか*.service
?- 本当に を使用する必要がある場合
*.mount
、これをユーザー バスで動作させるためのコツはありますか。それとも、システム バスに移動して、遅延マウントを実行して UID と GID を手動で設定する方法を理解する必要がありますか。
を使用することの利点の 1 つは*.service
、このサービスを に追加できるskel
ため、各ユーザーが自分のプライベート共有ディレクトリを自動マウントし、家中のすべてのマシン間で効果的に同期できることです。*.mount
正しいホームにアクセスするには、ファイル名にユーザー名が必要です。
答え1
Ubuntu 21.04 の systemd 246.6 でも同じ問題が発生します。マウント ユニットをアンマウントしようとすると、systemd は最初に でアンマウント ヘルパーを見つけようとします/sbin/umount.<type>
(つまり、sshfs の場合は/sbin/umount.fuse.sshfs
)。これが失敗すると が呼び出されumount2(<where>)
、ユーザーの systemd によって実行されると失敗します。
なぜこれが @fra-san で機能するのかはわかりませんが、アンマウント ヘルパーがあるのではないかと思います。
これらの質問に関して:
- SysV スタイルの init スクリプトで何でもできるのと同じように、サービス ユニットでも何でもできますが、systemd の考え方は、一般的なシステム管理タスクを理解し、物事を過度に複雑にすることなく (メンテナンスが難しくなるように)、必要なことを実現するための最小限の記述構文を提供することです。マウント ユニットを使用してファイル システムをマウントできる場合は、基本的にスクリプトを作成するよりも望ましいです。もちろん、インフラストラクチャは必要なことをサポートできる必要があります。Ubuntu 21.04 の時点で、ユーザー マウント ユニットの現在の状態は数年前よりもはるかに改善されていますが、FUSE ファイル システムではまだ 100% ではありません。
- ユーザマウントユニットを停止(アンマウント)するために、私は次のよう
fuse.sshfs
にumountヘルパーを作成しました。/sbin/umount.fuse.sshfs
#!/bin/sh
/bin/fusermount -u "$1"
その後、マウント ユニットを停止すると、うまく機能します。systemd は umount ヘルパーを呼び出して、ファイル システムを正しくアンマウントします ( umount
umount ヘルパーから呼び出さないでくださいumount
。ヘルパーも呼び出され、すべての pid を消費する無限ループに陥る可能性があるためです)。これはおそらく優れた解決策ではなく、systemd はumount
ユーザーとして呼び出したときに実行されるものを実行する必要があります (実際に何をするのかはわかりません) が、私の場合はうまく機能します。