Another option for network file sharing is
sshfs, which allows you to mount a remote directory locally over an encrypted connection.
It is very easy to configure and enabled by default on Raspbian if the
ssh server is. To check, look for this line somewhere in
/etc/sshd_config (that's sshd_config, not ssh_config); it is usually near the bottom:
Subsystem sftp /usr/lib/openssh/sftp-server
"sftp" is similar to sshfs but somewhat more awkward; they are both enabled by the same option. It should be uncommented (ie., no leading
#). If you can't find it, add it at the bottom, and restart ssh:
sudo systemctl restart ssh, then
systemctl status ssh to make sure there were no issues. You can do this while you are logged in via
ssh, as long as nothing goes wrong (in which case it may still be okay).
To use this, from another Pi (or anything with an
ssh client1); you'll need credentials for the user, who must have permission to access the remote path:
sshfs firstname.lastname@example.org:/home/pi /mnt/pi2
^ remote path after colon
The first bit is the same as an
user@hostname, but with a remote path prepended after a colon. The second arg is a local mount path. If this succeeds,
/mnt/pi2 will map to
/home/pi on the remote machine. You can use anything you like in either place (as long as they are real existing directories). You can also create multiple such mounts between the same hosts if you like, and in both directions.
If you want to allow non-root users access, they won't have it by default; see the
allow_other option below.
If it fails and it is not clear why, you can use
-vv as with ssh (ie.,
ssh -vv pi@...) to see some debugging output. You can also check
/var/log/auth.log on the remote pi to see if there is a reason given there.
sshfs mounts constantly. The one between my workstation or laptop and NAS/general purpose LAN server (which isn't a pi anymore, but it was for a long time, and it is now something very similar running Debian) is done at boot and is incredibly reliable; I can even put the work machine to sleep, and the connection is still there when it wakes. The only time it goes down is when the LAN fails. I have similar connections to off site servers, and these are also ridiculously stable.
However, to achieve that may require a bit of tweaking. Here's what I use in
You can find an explanation of these in
man sshd_config. They also make for more stable logins.
When I mount the NAS connection, I use:
sshfs -o reconnect,ServerAliveInterval=45,ServerAliveCountMax=2 ...
Pretty sure this is fundamental to having the connection survive when the client goes to sleep (ie., goes offline and comes back a while later).
Some other useful options:
You're probably already using this if you are using
ssh on a LAN where the IP's aren't static, since otherwise ssh gripes about host keys for a given IP having changed. Don't use that for outside connections though.
All the machines in my ecosystem are linux based with
ext4 filesystems. This option makes permissions and such transparent; you have the normal permissions of your user. Without that, only root can access the mount.
SSHFS is encrypted, which makes it a bit slower than eg.
NFS mounts, which I also use. When a Pi is involved, I get unencrypted NFS speeds of maybe 8-12 MB/s over wifi and 3-5 MB/s with sshfs. I still prefer sshfs for security (even on your own LAN it is worth being aware of all the other little things using it, especially if there are other people with their own devices).
If you are interested in NFS, I have a post about that here:
(Your question is a tidier and more appropriately generalized, so I've closed the other one as a dupe.)
- There's a google chrome
ssh plugin which works well and can do
sshfs mounting, you'll have to look for instructions online (it is fairly simple). Also, it is not quite true that anything with an
ssh client can do sshfs; on Android you are stuck with sftp.