I'm trying to do a network backup of a drive. There are two machines in this process.


  • Distant machine with 2 hards sda and sdb
  • sdb is the drive which needs backing up
  • two users exist, root and user


  • machine I'm on
  • working as user Alan, can go root when needed

I do the following on PC2:

sshfs root@PC1:/dev ~/Desktop/netdisk/

Mounts fine. I have sdb available in ~/Destkop/netdisk/. Next step:

sudo dd if=~/Destkop/netdisk/sdb | gzip -c > ~/Destkop/ddbackup/image.gz

Yields an error:

dd: opening `netdisk/sdb': Permission denied

When i check the permissions of sdb:

brw-rw---- 1 root    disk    0, 0 Jan  3 10:47 sdb

Since i ssh-ed to PC1 as root@PC1 doesn't that mean that I have root access to files mounted as sshfs?

From this example it seems it doesn't, is there a concept here that I'm missing?


The remote files are accessed as the remote user that you logged in as, i.e. root. There's no other way, really.

The error you're getting is due to permissions on the local side. It's an oddity in FUSE, which SSHFS is based on. By default, only the user who did the mounting can access a FUSE filesystem. Even root cannot access it. Preventing the root user from access isn't a security restriction, since root can su(1)/setuid(2) down to the user who mounted the filesystem, it's a limitation of FUSE's internal architecture. Since you did the mounting as a non-root user, also access the filesystem as that non-root user. Running dd under sudo isn't buying you anything here anyway, so just run

dd if=~/Destkop/netdisk/sdb | gzip -c > ~/Destkop/ddbackup/image.gz

which (useless use of dd) simplifies down to

dd if=~/Destkop/netdisk/sdb | gzip -c > ~/Destkop/ddbackup/image.gz

which useless use of cat simplifies down to

gzip <~/Destkop/netdisk/sdb >~/Destkop/ddbackup/image.gz

If sdb is a block device and not a regular file on the remote side, it can't work through a remote filesystem (if the device entry was a device entry, it would be the local device, which is undesirable). Use ssh to access it:

ssh root@PC1 cat /dev/sdb | gzip >~/Destkop/ddbackup/image.gz

In any case, you'd save bandwidth by doing the compression on the remote side:

ssh root@PC1 'gzip </dev/sdb' >~/Destkop/ddbackup/image.gz
  • Is there a way to restore it without using dd? – TheMeaningfulEngineer Jan 6 '13 at 11:11
  • 1
    @Alan You mean do the transfer in the other direction? Sure, just invert the redirections and replace gzip by gunzip: ssh root@PC1 'gunzip >/dev/sdb' <~/Desktop/ddbackup/image.gz – Gilles 'SO- stop being evil' Jan 6 '13 at 12:25

sshfs cannot handle block devices. It will treat everything as a file. You would need to get creative with ssh, dd, and command line redirection like so:

PC2 -> PC1:

dd of=/home/Alan/Desktop/image.iso < ssh root@PC1 "dd if=/dev/sdb"

or from PC1 -> PC2:

dd if=/dev/sdb | ssh root@PC2"dd of=/home/Alan/Desktop/image.iso"
  • 1
    That's true, but it's not what's causing the error, in fact — see my answer. The recommendation is in the right direction, but this is a useless use of dd, and it would save bandwidth to compress before sending. – Gilles 'SO- stop being evil' Jan 4 '13 at 0:41

You can use the mount option allow_other to allow you to access this device as any user. If you use this option, bear in mind that the Linux kernel has an unresolved security bug that affects FUSE.

sshfs -o allow_other root@PC1:/dev ~/Desktop/netdisk/

Ensure you also set user_allow_other in /etc/fuse.conf as well.

See this answer on serverfault.com for further detail.

  • If you intend to use the allow_other mount option like the answer above suggests, be aware that the Linux kernel has an unresolved security bug that affects FUSE. See github.com/libfuse/libfuse/issues/15 – MountainX Feb 12 '18 at 10:13
  • Thanks @MountainX, I've updated the answer to reflect that too. – Robert Steward May 23 '18 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.