5

Edit:

This question originally focused on the issue of reversing the direction of the ssh connection on the transfer, but I came to realize that wasn't what was causing the problems I run into, so I simplified it.

Though Ubuntu documentation of zfs only discusses send-receive via file, that approach is unfeasible with large data-sets. Oracle documentation recommends using ssh in pipe, i.e.,

# zfs send tank/dana@snap1 | ssh sys2 zfs recv newtank/dana

However, attempting this procedure with a test data-set I've created, containing a single 10M file, I run into the problem of Ubuntu Xenial's implementation of zfs (ZFS-on-Linux) requiring root privileges (on the receiving side):

$ sudo -i
# zfs send tank/dana@snap1 | ssh sys2 zfs recv newtank/dana
Permission denied the ZFS utilities must be run as root.
warning: cannot send 'tank/dana@snap1': Broken pipe

I tried to fix this issue by passing ssh the -t flag, i.e. issuing

# zfs send tank/dana@snap1 | ssh -t sys2 "sudo zfs recv newtank/dana"

which fails with

Pseudo-terminal will not be allocated because stdin is not a terminal.

before asking for sys2's credentials, after which the following messages are received:

sudo: no tty present and no askpass program specified
warning: cannot send 'tank/dana@snap1': Broken pipe

Attempting to perform a test transfer using the other direction, using

# ssh -t sys2 "sudo zfs send newtank/dana2@snap1" | zfs recv tank/dana2

simply hangs after asking for sys2's credentials. (Recall, each snapshot only contains a 10M file, so I believe it doesn't actually try to do anything, but I'm not sure why it hangs.)

Improve this question
2
1
sudo zfs send tank/dana@snap1 | ssh sys2Root zfs recv newtank/dana

where sys2root is an entry in ~/.ssh/config, ie: 

host sys2Root
  HostName 192.168.0.x
  User root
Improve this answer
4
  • 3
    Isn't it a really bad idea to allow ssh root login on my server? – Jonathan Y. Apr 29 '16 at 8:12
  • 1
    Yes, if your server is on a public IP, but theoretically less of an issue if you are on a secure private network. Unfortunately ZoL does not fully support ZFS delegations yet and this is the only reliable workaround I have found. – Derrick Apr 29 '16 at 14:17
  • 1
    Derrick, I can confirm that everything works as expected when allowing ssh root login. I agree that it should be much less of a concern when one of the servers in question is protected behind a private network, so that one could create a reverse ssh tunnel from it to the public server, then initiate the transfer from the public server's side. (However, given the current scope of the question, I'm reluctant to accept this answer as a solution to the general case.) – Jonathan Y. Apr 29 '16 at 17:11
  • 1
    Finding this SU answer, this seems to be a given state, at least until ZFS-on-Linux supports using zfs allow a la the other answer on that question. As such, I'll accept the answer with the comment that restricting root login to a forced command--as described in that answer--could further enhance security. – Jonathan Y. May 2 '16 at 10:08
2

Given that's normally considered a bad idea to allow root login via ssh, the alternative is to have the destination user, say foo, be sudoer on destination host, name it remote. Also, passwordless login is a plus.

Then, the following command will suffice

$ sudo zfs send <dataset1> | ssh foo@remote "sudo zfs recv <dataset2>"
Improve this answer

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.