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 pi@raspberrypi.local:/home/pi /mnt/pi2
^ remote path after colon
The first bit is the same as an ssh
login, 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.
I use 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 /etc/ssh/sshd_config
:
TCPKeepAlive yes
ClientAliveInterval 120
ClientAliveCountMax 15
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:
-o StrictHostKeyChecking=no,UserKnownHostsFile=/dev/null
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.
-o allow_other,default_permissions
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:
https://raspberrypi.stackexchange.com/a/75866/5538
(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.
nfs
or SMB depending on what you actually want to do.