Automount an sftp folder in appVM

I have an appVM only for accessing a specific sftp folder from a different Debian computer.
I created a bash script that mounts the folder using an ssh key and run the script to mount the folder each time manually.
Is there a way to auto run the bash script or maybe other way to auto mount the sftp folder each time the appVM starts?
Found a way to add a new line into /etc/fstab, but the change to fstab file is reset each time I restart the appVM

Have you tried /rw/config/rc.local?

Thanks @renehoj for your response, but I don’t know what exactly should I try to add to /rw/config/rc.local
Should it be the same line that is goes to /etc/fstab in regular linux?

No, you need to enter the same command you would use in the command line, rc.local is just a shell script that is run automatically during the boot sequence.

Ah, OK, let me try

I have added the next line to /rw/config/rc.local of the required qube:

sshfs -v -o IdentityFile=/home/user/.ssh/ssh_key ssh-user@192.168.01.11:/sftp/jails/sftp-folder /usr/local/sftp/sftp_mount

and restarted the qube but the sftp-folder was not mounted, at least the /usr/local/sftp/sftp_mount doesn’t contains anything.
I also executed the above line command manually and the sftp-folder was mounted and it’s not empty, that means the command itself it’s correct, it’s not executed looks like from /rw/config/rc.local

I don’t use sshfs, but I mount both nfs and webdav shares from rc.local.

You can try using the absolute path for sshfs, you can also pipe standard and error out to a file, it might tell you why it’s not working.

Thanks for output suggestion.
I redirected the output and error to a file and added debug:
sshfs -v -odebug,sshfs_debug,loglevel=debug -o IdentityFile=/home/user/.ssh/ssh_key ssh-user@192.168.01.11:/sftp/jails/sftp-folder /usr/local/sftp/sftp_mount 2>&1 | tee /home/user/Downloads/output.txt

the output I received:
debug1: read_passphrase: can't open /dev/tty: No such device or address Host key verification failed. read: Connection reset by peer

Google seems to think that Host key verification failed. is because of a mismatch with the user running the command and the expected ~/.ssh/known_hosts

What I did:
Added next code to /rw/config/rc.local

sshfs -v -odebug,sshfs_debug,loglevel=debug -o StrictHostKeyChecking=no -o IdentityFile=/home/user/.ssh/ssh_key -o allow_other ssh-user@192.168.01.11:/sftp/jails/sftop-folder /usr/local/sftp/sftp_mount 2>&1 | tee /home/user/Downloads/output.txt

and some time the sftp folder is mounted when the VM starts, but most of the time is not working.

The output error is:

SSHFS version 3.7.1
executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-ologlevel=debug> <-oStrictHostKeyChecking=no> <-oIdentityFile=/home/user/.ssh/ssh_key> <-2> <ssh-user@192.168.01.11> <-s> <sftp>
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 192.168.01.11 [192.168.01.11] port 22.
debug1: connect to address 192.168.01.11 port 22: Network is unreachable
ssh: connect to host 192.168.01.11 port 22: Network is unreachable
read: Connection reset by peer

When running same script/code manually it works, it mounts the sftp folder, without any issue (I’m using a bash script very similar to the above and it always works).
Why the same code not working from rc.local correctly all the time?

A wild guess: might the outcome depend whether or not the starting qube’s NetVM has finished establishing a connection to the network by the time rc.local is executed?

Troubleshooting: once the script runs successfully, does restarting the qube mount the directory successfully again?

To avoid timing issues with your sshfs AppVM, you may want to use the automount service (an example I used some times ago: mirage-sshfs/etc/README.md at main · palainp/mirage-sshfs · GitHub).

If you use automount the user executing the command is root, so the private key should be owned by root with permissions rw-------. Another issue is that sshfs will try to validate the hash signature of the server the first time if not present in .ssh/know_hosts as pointed by @renehoj, but the know_hosts file should be in the root homedir (and now you can remove -o StrictHostKeyChecking=no).

in my case the VM is using sys-firewall, so it should not be a problem as I have network access.
I have started the VM and the sftp folder was not mount, I run the command from the rc.local, verified the sftp folder was mounted (I see the content), so I exit the command, the sftp folder was unmounted automatically.
Restarted the VM again and same result, sftp folder was not mounted. Same output error as above Network is unreachable

I will try autofs .
Question here, I don’t have the /home/root folder (only /home/user). Should I create a /home/root/.ssh and then add ssh keys right?

BTW, who is running the rc.local, root or user?
When I run manually my bash script or code from rc.local to mount the sftp, I run as user, never with sudo.

The weird thing, is that in rare cases the sftp folder was mounted when the VM starts, but most of the times not.

The root homedir is /root.

With id>/tmp/test.txt you can check who is running the rc.local script, I just tried and have uid=0(root) gid=0(root) groups=0(root). That’s coherent with your HostChecking option setted to no :slight_smile:

I’m not sure why your results are erratic so far :frowning:

Does the appVM run SystemD?

If so, does SystemD wait for “network online” before running rc.local … or does SystemD [in it’s holy mantra of “being the fastest on the block”?] start rc.local between “network started” and “network online”?

I’ve been burned by SystemD (10 years ago), where it [on boot] would present the login screen, before the network was online - so LDAP authentication and users home folder (network drive) didn’t stand a change to be ready, when the user entered username and password … :-/

qubes-misc-post.service (which is responsible for running /rw/config/rc.local) is not ordered after network.target, so there’s no guarantee it will run after the network is up - but it probably happens occasionally.

Does it work reliably if you prepend the line

until systemctl is-active network.target; do sleep 1; done

before your sshfs line in rc.local?

2 Likes

Thanks @rustybird
I have added the sleep and after that my tests of the VM (restarted 10 times) were successful (the sftp folder was mounted each time consistently)

1 Like

Come to think of it, it would be better to run the sshfs command in rc.local through systemd-run. This way the ordering on network.target can be properly declared (= no need for the sleep line) so that it will also be reversed when it’s time to automatically unmount during VM shutdown. For example:

systemd-run --service-type=forking --uid=user -p Wants=network.target -p After=network.target sshfs ...
1 Like

Tried the @rustybird 's suggestion (thanks)
systemd-run ...
and it’s working too.

I’m not familiar with systemd and would appreciate if somebody could explain what is the difference by using the systemd-run ... (e.g. how it will be reversed when VM shutdown). Does this means I don’t need explicitly to run umount command to unmount the sftp mounted folder and just shutdown the VM, and it will take care automatically to umount the sftp folder?
Also if you could explain what --service-type=forking means/do in the command
Thanks a lot for helping me and educating