rsync with permission problems

[Chern Jian Leaw]

HI,

I'm trying to rsync filesystems between 2 NIS domains in which I do have accounts, with the same user name.

I'm trying to rsync a filesystem in which I'm not the owner of it, nor do I belong to its workgroup, from 1 machine(plxw0140.png.excel.com) to another machine(php.pdx.excel.com). Both of these machines are on 2 different NIS domains.

I invoked rsync as follows:
rsync -avl plxw0140.png.excel.com:/fs29/psdir /pgserver/restore/tmp

It produced the error:
rcmd2: socket: the file access permissions do not allow the specified action
unexpected EOF in read_timeout.

I've made the .rhosts file in my home directory of php.pdx.excel.com to have the following entry:
plxw0140.png.excel.com cjleaw

The .rhosts file in my home-dir of plxw0140.png.excel.com contains:
php.pdx.excel.com cjleaw

I do not however have root access to plxw0140.png.excel.com hence, I can't add php.pdx.excel.com cjleaw into the /.rhosts file.

can someone help me out ?

Thanks.

[Ian Box]

I believe rsync uses remsh by default to commumicate between the machines. Can you use remsh successfully?

I seem to remember having a similar problem with remsh when the permissions were wrong on the remsh executable. It didn't have the setuid bit on. When the permissions were changed to include setuid everything was OK.

Ian

[Chern Jian Leaw]

Ian,

could you elaborate more on how you've used remsh and setting of the setuid and setgid to work?

I'm pretty new in this area of rsync.

Thanks.

[Ian Box]

I'm not an expert on rsync, but I think that when you run your command:

rsync -avl plxw0140.png.excel.com:/fs29/psdir /pgserver/restore/tmp

it will use remsh on php.pdx.excel.com to run another rsync command on plxw0140.png.excel.com.

All I'm suggesting is that you try something simple like 'remsh plxw0140.png.excel.com ls -l'. If this produces the same error message as the rsync command then it implies some sort of problem with remsh. As I explained above, one possible cause of that might be if remsh doesn't have the setuid bit on, so it runs under your own ID instead of root. Doubtless there are other possible causes too.