[Solved] How to set up rsync server for encrypted transfers

[esousra]

Yes :) now I'm in. I'll just leave the user as "admin-nas".

As for the rsyncd changes, I'll try it tomorrow; too much noob'ing for today :) Have a nice evening!

[Jocko]

Hi

Did you make some tests to valid the rsync changes ?

[esousra]

Hi,

I applied the patch, and I get the extra option on the GUI; so that looks good:

1.png

However, I've been struggling to understand what happened to the permissions of the folders inside my shares. Randomly, some directories/files suddenly got 700 permissions, and I couldn't access them over SMB.

Recursively changing all to 755, I seem to be able to access everything (at least, cannot find a directory which I cannot open in Windows), but when I select to see properties of all the directories inside the share, Windows reports much smaller size than it should be.

Checking size in SSH console (du), the size is correct.

Could the patch have messed this up?

About the new functionality itself, it doesn't seen to work. Now I cannot even list the remote shares on the first screen (which before was working):

2.png

And if I choose "Remote Shell mode", now it doesn't even connect:

3.png

rsync log file is not showing anything on GUI.

[Jocko]

Hi

However, I've been struggling to understand what happened to the permissions of the folders inside my shares. Randomly, some directories/files suddenly got 700 permissions, and I couldn't access them over SMB.

Recursively changing all to 755, I seem to be able to access everything (at least, cannot find a directory which I cannot open in Windows), but when I select to see properties of all the directories inside the share, Windows reports much smaller size than it should be.

Checking size in SSH console (du), the size is correct.

Could the patch have messed this up?

No in all case but you made some remote shell transfer with the rsyncd. If you made a transfer from an laptop (MAC or linux) from the home directory of the current user account, it is the expected behaviour with permissions 700 as on your laptop, files have by default these permissions on the home directory.
So the files does not have the right permissions on the destination: should be 666 on files and 777 on folders.
You need first to restore these permissions on all files/shares. So do this command

Code: Select all

chmod -R a+rwX /share/*

(x must be an upper char)

About the options on your seagate OS, I think you should explore what they mean.

I do not understand what mean "secure data transfer" as for me remote shell mode is already the secure mode with rsync client (-e "xxxx").
Please to note I tested successful the changes between two nas (one with rsync daemon running) and the other with a rsync client line using the shell mode.

May be the issue is the ssh client which is not the ssh client provided with openssh but dbclient with our ssh server (dropbear). Maybe seagate os asks to use the client ssh in its command line. On your 2big2, you can try to create a symlink to fix this issue

Code: Select all

ln -s /usr/bin/dbclient /usr/bin/ssh

[esousra]

No in all case but you made some remote shell transfer with the rsyncd.

I didn't get to do it with rsyncd. I just saw that it could connect with the secure shell mode; but those files are the same as they have been since first 2big NAS (when it was still in RAID1) -> 2big2 rsync, which I did with the unencrypted user.

If you made a transfer from an laptop (MAC or linux) from the home directory of the current user account, it is the expected behavior with permissions 700 as on your laptop, files have by default these permissions on the home directory.

Also no, I have only Windows.

Code: Select all

chmod -R a+rwX /share/*

Doesn't seem to help, Windows still stops short of counting the size of all files.
It's interesting that this only happens on the Backup share; not on the Pictures share...

Code: Select all

ln -s /usr/bin/dbclient /usr/bin/ssh

Also didn't help...

Anyways, understood why I couldn't do remote shell now. rsyncd also requests the certificate:

1.png

I don't think I can configure Seagate OS to use a cert, so I've instead disabled that on the 2big2 (after setting new passwd for root on the console).

So I think I'll stick to this.

[Jocko]

I didn't get to do it with rsyncd. I just saw that it could connect with the secure shell mode

it is what I said. With remote shell you have an umask value which removes some permissions.

I don't think I can configure Seagate OS to use a cert, so I've instead disabled that on the 2big2 (after setting new passwd for root on the console).

Yes like seagate seems to use basic options on the remote shell, it can not use a rsa key to connect (even if rsync client allows it :whistle )

It you go back about shell mode, you will get again your issue about the root password. So before restoring the password mode, you need to reset the root password. You can not use rsyncd login to do it (of course!)

Code: Select all

unlink: cannot unlink `symlink.txt': Permission denied

I go to send you a pm how to reset root password.

[esousra]

It's Ok, thanks, I already reset it (passwd on ssh console after logging in with cert) :) I can now login with root user & pwd.

[Jocko]

if you used the command 'passwd' to reset the root password. It is not enough: on next rebooting the forgotten password will be restored :whistle

[esousra]

Thanks :) I've tried your PM instruction, and it works fine, even after rebooting.

[Jocko]

Hi,

And now with the root account restored, did you make again new tries to use rsync over a shell access.

(Please to test it also with or not the symlink ssh)

Thank you