Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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

PC1:

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

PC2:

  • 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?

share|improve this question
add comment

3 Answers

up vote 2 down vote accepted

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
share|improve this answer
    
Is there a way to restore it without using dd? –  Alan 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 Jan 6 '13 at 12:25
add comment

You can use the mount option allow_other to allow you to access this device as any user.

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.

share|improve this answer
add comment

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"
share|improve this answer
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 Jan 4 '13 at 0:41
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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