[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Persistent sshfs mount from inside a Buster virtual machine?



Here is where I am at now.  Inspired by em's posts I went back and looked back
at the Arch Wiki and decided to start from basics and try getting the mount
working from /etc/fstab and that succeeded.  Doing so led me to read the
systemd.automount(5) and systemd.mount(5) pages a bit more carefully again.  In
the systemd.mount page it is declared that setting up mounts such as
this--sshfs, automounts, etc.--in /etc/fstab is generally preferred so I am
taking that approach rather than wrting unit files.

BTW, em mentioned having to mount, or rather at least log into the host from
the root account, that is to put the host's signature into
/root/.ssh/known_hosts.  I'm not an SSH expert but have found that a SSH shell
login is required to save the remote host's signature before sshfs will work.

Follows is a relevant line for one of my sshfs mounts in /etc/fstab on the
Buster guest:

nate@10.0.2.2:/home/nate/vbox-shr /home/nate/share fuse.sshfs x-systemd.automount,x-systemd.idle-timeout=0,_netdev,user,idmap=user,follow_symlinks,identityfile=/home/nate/.ssh/id_merlin,allow_other,default_permissions,uid=1000,gid=1000 0 0

Based on this line systemd creates two files in /run/systemd/generator,
home-nate-share.automount and home-nate-share.mount at system boot.

Follows are the contents of each file:

# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=remote-fs.target

[Automount]
Where=/home/nate/share
TimeoutIdleSec=infinity

------------8<----------------------->8------------

# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)

[Mount]
Where=/home/nate/share
What=nate@10.0.2.2:/home/nate/vbox-shr
Type=fuse.sshfs
Options=x-systemd.automount,x-systemd.idle-timeout=0,_netdev,user,idmap=user,follow_symlinks,identityfile=/home/nate/.ssh/id_merlin,
allow_other,default_permissions,uid=1000,gid=1000


As can be seen, x-systemd.automount transforms the fstab stanza into a systemd
automount and transforms x-systemd.idle-timeout=0 to TimeoutIdleSec=infinity in
the generated automount unit.  In the mount unit file it can be seen that the
fstab stanza is transformed into various fields.  So far, so good.

But Debian, we have a problem.  The systemd.automount(5) page states that the
timeout is disabled by default.  However, my first email noted the mount point
being unmounted after five minutes.  This is still the case even though the
timeout value is explicitly set to '0' in fstab and the systemd generator
interprets this as being 'infinity' for the automount unit file, clearly this
is not being respected elsewhere in the Buster version of systemd as the share
is unmounted after 5 minutes.  I tried a value of '30m' to no effect.

I even tried the following stanza in fstab:

nate@10.0.2.2:/home/nate/vbox-shr /home/nate/share fuse.sshfs auto,_netdev,user,idmap=user,follow_symlinks,identityfile=/home/nate/.ssh/id_merlin,allow_other,default_permissions,uid=1000,gid=1000 0 0

and the share is mounted at system boot but is unmounted after five minutes.

As I see it, per the systemd documentation, this is not the intended behavior
yet I see it happening.  Regular disk mounts do not suffer from this timeout
and the SSH ServerAliveInterval also appears to have no effect, so I am
thinking a bug exists in systemd.

Finally, here is a recent journalctl output where it can be seen that share is
mounted and then unmounted:

$ journalctl -f
-- Logs begin at Fri 2020-04-24 14:33:01 CDT. --
Apr 24 14:33:53 buster systemd[563]: Reached target Default.
Apr 24 14:33:53 buster systemd[1]: Started User Manager for UID 1000.
Apr 24 14:33:53 buster systemd[563]: Startup finished in 37ms.
Apr 24 14:33:53 buster systemd[1]: Started Session 2 of user nate.
Apr 24 14:36:33 buster systemd[1]: home-nate-share.automount: Got automount request for /home/nate/share, triggered by 630 (ls)
Apr 24 14:36:33 buster systemd[1]: Mounting /home/nate/share...
Apr 24 14:36:33 buster kernel: fuse init (API version 7.27)
Apr 24 14:36:33 buster systemd[1]: Mounting FUSE Control File System...
Apr 24 14:36:33 buster systemd[1]: Mounted FUSE Control File System.
Apr 24 14:36:33 buster systemd[1]: Mounted /home/nate/share.
Apr 24 14:42:02 buster systemd[563]: home-nate-share.mount: Succeeded.
Apr 24 14:42:02 buster systemd[510]: home-nate-share.mount: Succeeded.
Apr 24 14:42:02 buster systemd[1]: home-nate-share.mount: Succeeded.


Oddly, timing shows this share was mounted for about five and a half minutes.
Around five minutes seems to be the norm.

Looking a bit further back in the logs, the systemd[510] process is for
the lightdm pam_unix session and systemd[563] is for the nate pam_uniz
session.  It appears the unmount was initiated by the systemd[563]
process.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

Attachment: signature.asc
Description: PGP signature


Reply to: