rsync issues and questions

Questions and mods regarding system management may go here
Forum rules
We've moved! Head over to Synology Community (community.synology.com) to meet up with our team and other Synology enthusiasts!
geohei
Experienced
Experienced
Posts: 111
Joined: Wed Aug 02, 2017 10:58 am

rsync issues and questions

Unread post by geohei » Mon Aug 28, 2017 12:19 pm

Hi.

I spent quite some time to find out by trial and error how the Synology rsync daemon works. It seems that it is highly customized!

1. (Test done in a DSM VM)
user:group at destination host (DSM) changes whether I use the linux path (/volume1/NetBackup), or the module name (::NetBackup).

Code: Select all

:~# rsync -rlptogvDR -e ssh "/home/geohei/" jw@192.168.11.174:/volume1/NetBackup/
...
:~# rsync -rlptogvDR -e ssh "/home/geohei/" jw@192.168.11.174::NetBackup/
...

Code: Select all

#:/volume1/NetBackup# ls -l
total 0
drwxrwxrwx+ 1 root root   8 Aug 28 07:51 @eaDir
drwxr-xr-x  1 jw   users 12 Feb 14  2015 home
d---------+ 1 root root  78 Aug 28 11:58 #recycle
...
#:/volume1/NetBackup# ls -l
total 0
drwxrwxrwx+ 1 root root  8 Aug 28 07:51 @eaDir
drwxr-xr-x  1 root root 12 Feb 14  2015 home
d---------+ 1 root root 78 Aug 28 11:58 #recycle
...
The first is the user:group of the DSM user used in the rsync command.
The second is the user:group of the source file (preserved).

2. (Test done in a DSM VM)
When creating manually an identical folder "abc" as "NetBackup" (which was created automatically when enabling rsync service on DSM), the user:group also changes when copying using module name (::NetBackup).

Code: Select all

#:/volume1# ls -l abc/home/
total 0
drwxr-xr-x 1 jw users 100 Aug 13 15:27 geohei
root@vm-neelix:/volume1# ls -l NetBackup/
total 0
drwxrwxrwx+ 1 root root  8 Aug 28 07:51 @eaDir
drwxr-xr-x  1 root root 12 Feb 14  2015 home
d---------+ 1 root root 78 Aug 28 11:58 #recycle
The first is the user:group of the DSM user used in the rsync command.
The second is the user:group of the source files.

3.
There also seems to be a difference between the native DSM an a DSM running in the VM.

1. and 2. above would suggest, that rsync's in the module ::NetBackup always preserves user:group from the source host. However I found out, that this is only true for DSM running in a VM. If the DSM is native, then (for some reason ?!?!) only the group is preserved from the source system, but the user changes into the first user created (which is the user created during the DSM installation process). No clue which logic is behind this ... ?!?!

Bottom line ...

I'd like to keep the user:group from the source system, while using my own backup folder "abc" i.s.o. "NetBackup".

There are (hidden) differences between both folders. How can I change the permisions/settings of "abc" them in order to match with "NetBackup"?

Thanks,

nixjps
Apprentice
Apprentice
Posts: 98
Joined: Fri Jun 09, 2017 1:39 pm

Re: rsync issues and questions

Unread post by nixjps » Wed Aug 30, 2017 12:02 pm

Hi,
geohei wrote:Hi.
I spent quite some time to find out by trial and error how the Synology rsync daemon works. It seems that it is highly customized!
Your are correct, Synology's rsync is customized. The actual Synology version (3.0.9 pretty outdated isn't it ;-D) is available on sourceforge...

Note that the behaviors you describe are conform to synology's documentation (see first note on https://www.synology.com/en-global/know ... file_rsync).
To preserve ownership on a DSM destination, there is only one way.... Use module "NetBackup", hence run rsync in daemon mode. In addition, the user on destination side must be member of the administrators group....
Period....
Otherwise ownership will not be preserved (or depending on what login options you try you may end in a "service disabled" response...).
I don't believe there is a way to have another share (module) behave as "NetBackup" (it's "hardcoded" in Synology's rsync source code)....
geohei wrote: [...]

Code: Select all

:~# rsync -rlptogvDR -e ssh "/home/geohei/" jw@192.168.11.174:/volume1/NetBackup/
...
:~# rsync -rlptogvDR -e ssh "/home/geohei/" jw@192.168.11.174::NetBackup/
...
I am sure you know, but for some readers a couple of explanations may help.

Code: Select all

rsync -rlptogvDR -e ssh "/home/geohei/" jw@192.168.11.174:/volume1/NetBackup/ 
The above uses the ssh stream version of rsync. In other words, we launch rsync as client on one side of the stream and rsync as server on the other side.
In this scenario, to preserve owner ship we must be super user on destination side (or use --super option).

BTW, using "-e ssh" is not mandatory as it's used by default in this case. You would need to specify -e only to add additional parameters to you ssh (-p n port instance or override user with -l, ....). You may also replace -rlptogvDR with -avR.

Your rsync client will run ssh -l jw 192.168.11.174 rsync --server [options] . /volume1/NetBackup
[options] be replaced by a set of options based on what you passed to your rsync client.
Destination files will be owned by jw... Server will try to set ownership but it will fail due to permission. On a non synology you would be able to use super user on the server side....

But on a synology box it will tell "service disabled"....
You have an alternative, it may not suit your workflow.... But assuming that system hosting "/home/geohei" is a "standard" rsync and host ip is A.... You could run your command from the DSM box....
As

Code: Select all

admin@192.168.11.174 $ sudo rsync -avR user@A:/home/geohei /volume1/NetBackup
# or if needed
admin@192.168.11.174 $ sudo rsync -avR "-e ssh -l root" A:/home/geohei /volume1/NetBackup
 
This should work. /home/geohei will be synced to your synology in /volume1/NetBackup (or any other destination) permissions and ownership will be preserved because the client is run as super user.

Code: Select all

:~# rsync -rlptogvDR -e ssh "/home/geohei/" jw@192.168.11.174::NetBackup/ 
That one runs in daemon mode because of the presence of the "::"
On a traditional rsync, NetBackup would be a module defined in /etc/rsyncd.conf. On a synology it is a the shared folder "NetBackup" (could be also a module defined in /etc/rsyncd.conf)

The presence of -e ssh will force the daemon to run over an ssh stream (otherwise communication between hosts is not encrypted and achieved through a connection where a rsync daemon is listening).
So, when you have ssh, instead of launching a command "rsync --server" on other side of the stream as when using single ":", it will launch "rsync --server --daemon"
Note that unless you explicitly gave an -l user option in -e, ssh will be called with -l jw append to it...
Files ownership at destination will be the ones of the jw (login user) or the uid set in /etc/rsyncd.conf for that module. On a non synology box, ownership will be set to source if login user is super user... On a DSM box, root is disabled.... If loging is member of Administrator group and module has predefined value NetBackup, then ownership is set to source...
geohei wrote:

Code: Select all

#:/volume1/NetBackup# ls -l
[...]
drwxr-xr-x  1 jw   users 12 Feb 14  2015 home
[...]
#:/volume1/NetBackup# ls -l
[...]
drwxr-xr-x  1 root root 12 Feb 14  2015 home
The first is the user:group of the DSM user used in the rsync command.
The second is the user:group of the source file (preserved).
Correct, and according to DSM documentation, this is what should be expected as you are using client/server mode in first case and NetBackup module - daemon mode - as destination in second case.... (assuming jw is member of administrators group). I believe that when user is not member of administrators group, then, though ownership is set to destination user, group membeship is set to source. Need to be checked.
geohei wrote: [....]
Bottom line ...
I'd like to keep the user:group from the source system, while using my own backup folder "abc" i.s.o. "NetBackup".
[...]
How can I change the permisions/settings of "abc" them in order to match with "NetBackup"?
With synology as destination and by running rsync from source host? ... I believe there is no way to have this out of the box....
The alternative is to start your client on the DSM and run the server on the source or cross compile a standard rsync and install it on your DSM.... For the latter, assuming you installed the binary in /var/services/homes/admin/bin you would run:

Code: Select all

:~# rsync -rlptogvDR --rsync-path /var/services/homes/admin/rsync /home/geohei/  root@192.168.11.174:/volume1/aSharedFolderABC/
# it implies of course that you have setup /root/.ssh/* files properly
# you may also try
:~# rsync -rlptogvDR --super --rsync-path /var/services/homes/admin/rsync /home/geohei/  admin@192.168.11.174:/volume1/aSharedFolderABC/
# you could also use the module syntax assuming you have defined them in /etc/rsyncd.conf
# rsyncd.conf should be preserved during DSM updates as DSM documentations suggest to modify this file when required.
 
Rgds
DS916+ (8G) - DSM 6.1.3-15152u4 - ST8000VN0022-2EL112 x 3 - 1 SHR Disk Group - 2 volumes - Home Usage
DS216Play - DSM 6.1.3-15152u4 - ST4000DM000-1F2168 x 2 - Basic Disks - 2 Volumes - Off site backup of DS916+ and local browsing of Photos, Musics and Videos
DS916 and DS216Play MAN link (1Gb FFTH same ISP).
DS916 S2S -> DS216Play, HyperBackup of DS916 config & critical data to DS216Play. HyperBackup of DS216Play configuration and local data to DS916

User avatar
PaulS
Enlightened
Enlightened
Posts: 437
Joined: Thu May 02, 2013 1:52 pm

Re: rsync issues and questions

Unread post by PaulS » Wed Aug 30, 2017 2:39 pm

geohei wrote:I'd like to keep the user:group from the source system, while using my own backup folder "abc" i.s.o. "NetBackup".
I use the chown= and chmod= rsync switches to maintain attributes and ownership with rsyc to DSM. Also, I've seen more consistent results and far faster performance going between NFS shares.

nixjps
Apprentice
Apprentice
Posts: 98
Joined: Fri Jun 09, 2017 1:39 pm

Re: rsync issues and questions

Unread post by nixjps » Wed Aug 30, 2017 3:39 pm

PaulS wrote:
geohei wrote:I'd like to keep the user:group from the source system, while using my own backup folder "abc" i.s.o. "NetBackup".
I use the chown= and chmod= rsync switches to maintain attributes and ownership with rsyc to DSM. Also, I've seen more consistent results and far faster performance going between NFS shares.
In the context of OP (rsync client/server model through network) I don't believe that --chown switch is relevant, indeed as of DSM 6, that switch is not available as synology rsync used does not support it.
It came later (see rsync-3.1.0-NEWS).
Further, chown switch does not exactly preserve owner:group of source files. It's a way to set owner:group to defined values once all files synced.

Er.... now.... you have point...
You are proposing an interesting approach.
If geohei uses NFS (or another protocol) to mount the remote synology folder, rsync will be used in local copy mode....
Hence, it will open all options available on the standard rsync program without being annoyed by the Synology rsync restrictions...

Rgds,
DS916+ (8G) - DSM 6.1.3-15152u4 - ST8000VN0022-2EL112 x 3 - 1 SHR Disk Group - 2 volumes - Home Usage
DS216Play - DSM 6.1.3-15152u4 - ST4000DM000-1F2168 x 2 - Basic Disks - 2 Volumes - Off site backup of DS916+ and local browsing of Photos, Musics and Videos
DS916 and DS216Play MAN link (1Gb FFTH same ISP).
DS916 S2S -> DS216Play, HyperBackup of DS916 config & critical data to DS216Play. HyperBackup of DS216Play configuration and local data to DS916

geohei
Experienced
Experienced
Posts: 111
Joined: Wed Aug 02, 2017 10:58 am

Re: rsync issues and questions

Unread post by geohei » Thu Aug 31, 2017 9:08 pm

@nixjps
Wow ... what a posting ... !!!
Thanks a lot !!!

I'll get some coffee ...
nixjps wrote:To preserve ownership on a DSM destination, there is only one way.... Use module "NetBackup", hence run rsync in daemon mode. In addition, the user on destination side must be member of the administrators group....
Period....
Otherwise ownership will not be preserved (or depending on what login options you try you may end in a "service disabled" response...).
I don't believe there is a way to have another share (module) behave as "NetBackup" (it's "hardcoded" in Synology's rsync source code)....
I expected the hardcoded module NetBackup. Thanks for confirmation!
Also, the user on DSM needs to be member of the administrators group - confirmed!
I'd like to add that the client needs to say -og and --numeric-ids (otherwise mapping takes place on DSM).
nixjps wrote:

Code: Select all

rsync -rlptogvDR -e ssh "/home/geohei/" jw@192.168.11.174:/volume1/NetBackup/
The above uses the ssh stream version of rsync. In other words, we launch rsync as client on one side of the stream and rsync as server on the other side.
In this scenario, to preserve owner ship we must be super user on destination side (or use --super option).

BTW, using "-e ssh" is not mandatory as it's used by default in this case. You would need to specify -e only to add additional parameters to you ssh (-p n port instance or override user with -l, ....). You may also replace -rlptogvDR with -avR.
Since rsync on DSM is launched as root, ownership preservation is possible.

Thanks for the info that "-e ssh" is default. Missed that indeed.

I keep -rlptogvDR options for the moment for testing purpose. Probably, I'll kuck some options (like -D, ...) out until the final version is up and running as desired!
nixjps wrote:

Code: Select all

admin@192.168.11.174 $ sudo rsync -avR "-e ssh -l root" A:/home/geohei /volume1/NetBackup

Code: Select all

root@192.168.11.174 $ rsync -avR --numeric-ids "-e ssh -l geohei" A:/home/geohei /::test
This worked!
Never thought to reverse the roles client/server.
Also ... uid:gid is preserved and ... the target folder is not (!) NetBackup.
nixjps wrote:

Code: Select all

:~# rsync -rlptogvDR -e ssh "/home/geohei/" jw@192.168.11.174::NetBackup/
That one runs in daemon mode because of the presence of the "::"
On a traditional rsync, NetBackup would be a module defined in /etc/rsyncd.conf. On a synology it is a the shared folder "NetBackup" (could be also a module defined in /etc/rsyncd.conf)[/quote]
What about defining a module in rsyncd.conf? Would this not generate an equivalent to NetBackup, id est permitting to preverse uid:gid, just as it is with NetBackup?

... later ...

Tried this ...

Code: Select all

rsync -rlptogvDR -e ssh --numeric-ids "/home/geohei/" jw@192.168.11.174::QQQ
... with /etc/rsyncd.conf

Code: Select all

#motd file = /etc/rsyncd.motd
#log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
use chroot = no

[QQQ]
path = /volume1/abc
comment = test directory
read only = false
uid:gid is not preserved!

Do I need to add some options in the module definition?
nixjps wrote:
geohei wrote: ...
The first is the user:group of the DSM user used in the rsync command.
The second is the user:group of the source file (preserved).
Correct, and according to DSM documentation, this is what should be expected as you are using client/server mode in first case and NetBackup module - daemon mode - as destination in second case.... (assuming jw is member of administrators group). I believe that when user is not member of administrators group, then, though ownership is set to destination user, group membeship is set to source. Need to be checked.
If destination user is not member of administrators group, the user and group are the default uid:gid as in destination /etc/passwd (as for --server mode, not -daemon mode).

Again ... this was a gret job you did here. Makes things a lot clearer! However it will take me some more time to completely simulate your ideas!

Many thanks !!!

nixjps
Apprentice
Apprentice
Posts: 98
Joined: Fri Jun 09, 2017 1:39 pm

Re: rsync issues and questions

Unread post by nixjps » Fri Sep 01, 2017 4:52 pm

geohei wrote:@nixjps
Wow ... what a posting ... !!!
Thanks a lot !!!

I'll get some coffee ...
:-D
Hope coffee was good ;-]
geohei wrote:
nixjps wrote:To preserve ownership on a DSM destination, there is only one way.... Use module "NetBackup", hence run rsync in daemon mode. In addition, the user on destination side must be member of the administrators group....
Period....
Otherwise ownership will not be preserved (or depending on what login options you try you may end in a "service disabled" response...).
I don't believe there is a way to have another share (module) behave as "NetBackup" (it's "hardcoded" in Synology's rsync source code)....
I expected the hardcoded module NetBackup. Thanks for confirmation!
Well.... Actually, there is a way to preserve ownership when not using "NetBackup". Thanks to your comment later in your post I realize I should have think carefully before writing....
Indeed we can and may influence synology's rsync behavior with /etc/rsyncd.conf.
geohei wrote: Also, the user on DSM needs to be member of the administrators group - confirmed!
I'd like to add that the client needs to say -og and --numeric-ids (otherwise mapping takes place on DSM).
Correct! -og is required, indeed important point to recall.
As for --numeric-ids... Not absolutely required but indeed may be an option to recommend. Sometimes user mapping may be desirable, sometimes not...
geohei wrote:
nixjps wrote:

Code: Select all

rsync -rlptogvDR -e ssh "/home/geohei/" jw@192.168.11.174:/volume1/NetBackup/
The above uses the ssh stream version of rsync. In other words, we launch rsync as client on one side of the stream and rsync as server on the other side. In this scenario, to preserve owner ship we must be super user on destination side (or use --super option).
[...]
Since rsync on DSM is launched as root, ownership preservation is possible.
Ok... rsync has setuid set and is owned by root, so indeed when it's launched its effective uid is root.
However with the command "rsync -rlptogvDR -e ssh "/home/geohei/" jw@192.168.11.174:/volume1/NetBackup" real uid of the server process will be jw.... Synology's rsync uses that real id to make some decisions.
geohei wrote: What about defining a module in rsyncd.conf? Would this not generate an equivalent to NetBackup, id est permitting to preverse uid:gid, just as it is with NetBackup?
Yes good point.... This actually how you can workaround the synology blocker...
You can create a module with a new name or even use the name of an existing share (this will override the default settings).
geohei wrote: Tried this ...

Code: Select all

rsync -rlptogvDR -e ssh --numeric-ids "/home/geohei/" jw@192.168.11.174::QQQ
... with /etc/rsyncd.conf

Code: Select all

#motd file = /etc/rsyncd.motd
#log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
use chroot = no

[QQQ]
path = /volume1/abc
comment = test directory
read only = false
uid:gid is not preserved!

Do I need to add some options in the module definition?
Yes, just add uid = root
Once done,

Code: Select all

rsync -rlptogvDR -e ssh --numeric-ids "/home/geohei/" jw@192.168.11.174::QQQ
Will not preserve ownership because it's run as jw.... but

Code: Select all

rsync -rlptogvDR -e ssh --numeric-ids "/home/geohei/" root@192.168.11.174::QQQ
or

Code: Select all

rsync -rlptogvDR -e "ssh -l root" --numeric-ids "/home/geohei/" jw@192.168.11.174::QQQ
Will preserve ownership. Give it a try. That should suit your needs. For security reason it might be useful to configure for that share the "auth users" parameter as well as "hosts allow" and/or "hosts deny"
Rsyncd.conf Documentation wrote: uid This parameter specifies the user name or user ID that file transfers to and from that module should take place as when the daemon was run as root. [...]The default for a non-super-user is to not try to change the user.
For the record. Synology added a couple of options to their rsync. I'm thinking about "--syno-pseudo-root", it seems that when i'ts used in a --server --daemon context, rsync ignores the additional synology's restrictions. (It then works like above module/share QQQ. This option can be used directly if both hosts are running DSMs. Otherwise we need on the client side an rsync version that supports "--remote-option" option to passe the "--syno-pseudo-root" switch to the server.

Hope we are making progress ;-D.
Have a great weekend.
Rgds,
DS916+ (8G) - DSM 6.1.3-15152u4 - ST8000VN0022-2EL112 x 3 - 1 SHR Disk Group - 2 volumes - Home Usage
DS216Play - DSM 6.1.3-15152u4 - ST4000DM000-1F2168 x 2 - Basic Disks - 2 Volumes - Off site backup of DS916+ and local browsing of Photos, Musics and Videos
DS916 and DS216Play MAN link (1Gb FFTH same ISP).
DS916 S2S -> DS216Play, HyperBackup of DS916 config & critical data to DS216Play. HyperBackup of DS216Play configuration and local data to DS916

geohei
Experienced
Experienced
Posts: 111
Joined: Wed Aug 02, 2017 10:58 am

Re: rsync issues and questions

Unread post by geohei » Sat Sep 02, 2017 3:21 pm

Hi.
nixjps wrote:...

Yes good point.... This actually how you can workaround the synology blocker...
You can create a module with a new name or even use the name of an existing share (this will override the default settings).
geohei wrote: Tried this ...

Code: Select all

rsync -rlptogvDR -e ssh --numeric-ids "/home/geohei/" jw@192.168.11.174::QQQ
... with /etc/rsyncd.conf

Code: Select all

#motd file = /etc/rsyncd.motd
#log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
use chroot = no

[QQQ]
path = /volume1/abc
comment = test directory
read only = false
uid:gid is not preserved!

Do I need to add some options in the module definition?
Yes, just add uid = root
Once done,

Code: Select all

rsync -rlptogvDR -e ssh --numeric-ids "/home/geohei/" jw@192.168.11.174::QQQ
Will not preserve ownership because it's run as jw.... but

Code: Select all

rsync -rlptogvDR -e ssh --numeric-ids "/home/geohei/" root@192.168.11.174::QQQ
or

Code: Select all

rsync -rlptogvDR -e "ssh -l root" --numeric-ids "/home/geohei/" jw@192.168.11.174::QQQ
Will preserve ownership. Give it a try. That should suit your needs. For security reason it might be useful to configure for that share the "auth users" parameter as well as "hosts allow" and/or "hosts deny"
Rsyncd.conf Documentation wrote: uid This parameter specifies the user name or user ID that file transfers to and from that module should take place as when the daemon was run as root. [...]The default for a non-super-user is to not try to change the user.
What shall I say ... all works as you explained!

Which method would you give preference and why?
1. ... root@192.168.11.174::QQQ
2. ... -e "ssh -l root" ...

This requires however to set a root password, which is not the case when DSM is installed out of the box.
Just to make it complete ...

Code: Select all

$ synouser --setpw root <root password>
rsync transfer w/o password also requires ssh key exchange from client to root@DSM.

Code: Select all

$ ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.11.174
Thanks also for the additional security hints! Gonna check these out ...

BTW ... the coffee was crap, but I took another one!

nixjps
Apprentice
Apprentice
Posts: 98
Joined: Fri Jun 09, 2017 1:39 pm

Re: rsync issues and questions

Unread post by nixjps » Mon Sep 04, 2017 12:27 pm

Hi,
geohei wrote: [...]
Which method would you give preference and why?
1. ... root@192.168.11.174::QQQ
2. ... -e "ssh -l root" ...
[...]
In script or cmdline snapshots I would rather prefer 2.
Indeed, something like ... - e "ssh -l root" ... jw@192.168.1.174:QQQ, does, somehow, remind initial intention which is along the line of "I'm running this as root but I wish I could do it with user jw" ;-D
geohei wrote: [...]
This requires however to set a root password, which is not the case when DSM is installed out of the box.
Just to make it complete ...

Code: Select all

$ synouser --setpw root <root password>
rsync transfer w/o password also requires ssh key exchange from client to root@DSM.

Code: Select all

$ ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.11.174
[...]
Well.... Right.... though.... I would not set a root password on target DSM and would certainly take your second approach, which is configuring passwordless ssh for target DSM (when and only when sshed from the device that hosts "/home/geohei" and only from a secured account).

Actually, if you do not feel confortable - quite rightly - with ssh as root on target DSM, there is an alternative that works well on DSM (as any other *ix)....

Assuming jw on 192.168.11.174 is member of the administrators group (as you pointed out earlier, needed to ssh into the account).
You could add the below line at the end of your /etc/sudoers file.

Code: Select all

jw ALL=(ALL) NOPASSWD:/usr/bin/rsync
Be careful when modifying that file.... DSM has no visudo, so you need to edit with you favorite editor.... If file has a syntax error, or file permission is screwed, you won't be able to use sudo anymore, hence login as root.... ;-O.....
Best is to make a a backup of original file and have a second open window to check whether it's all right. So in case you made a mistake you can restore original one (from cmd line is you still have an open shell or from DSM task manager).

Once you have done this, user jw can run rsync as root without password.....

Code: Select all

rsync -rlptogvDR -e ssh --numeric-ids --rsync-path="sudo rsync" "/home/geohei/" jw@192.168.11.174::QQQ
Will preserve ownership of all the source files.....
If ~jw/.ssh on 192.168.11.174 is configured for passwordless ssh, above command will run without even asking for a password.

PS: For the record. You may notice from /etc/sudoers that if a user is member of group wheel, he can run rsync without password as well. So adding jw to group wheel (/etc/group) instead of creating a "jw" entry in /etc/sudoers would work as well. But that would allow jw to run any command as root (except shell and su) with no password.... Probably not something you want ;-D.

geohei wrote: BTW ... the coffee was crap, but I took another one!
;-D
Cheers,
DS916+ (8G) - DSM 6.1.3-15152u4 - ST8000VN0022-2EL112 x 3 - 1 SHR Disk Group - 2 volumes - Home Usage
DS216Play - DSM 6.1.3-15152u4 - ST4000DM000-1F2168 x 2 - Basic Disks - 2 Volumes - Off site backup of DS916+ and local browsing of Photos, Musics and Videos
DS916 and DS216Play MAN link (1Gb FFTH same ISP).
DS916 S2S -> DS216Play, HyperBackup of DS916 config & critical data to DS216Play. HyperBackup of DS216Play configuration and local data to DS916

geohei
Experienced
Experienced
Posts: 111
Joined: Wed Aug 02, 2017 10:58 am

Re: rsync issues and questions

Unread post by geohei » Mon Sep 04, 2017 3:49 pm

Hi.
nixjps wrote:...
Indeed, something like ... - e "ssh -l root" ... jw@192.168.1.174:QQQ, does, somehow, remind initial intention which is along the line of "I'm running this as root but I wish I could do it with user jw" ;-D
Right! Done!

I'll check you idea withh /etc/sudoers later. Thanks.

First this here I bumped into ...

I was very proud to have it the way I planned it, that I started actual testing with actual servers.

1. Server is a local Ubuntu 14.04 machine. rsync 3.1.0 protocol 31.
2. Server is a remote Ubuntu 12.04 machine (hoster). rsync 3.0.9 protocol 30.

/etc/rsync.conf (on NAS)

Code: Select all

#motd file = /etc/rsyncd.motd
#log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
use chroot = no

[QQQ]
path = /volume1/abc
comment = module for rsync backups
read only = false
uid = root
When I say ...

Code: Select all

root@server1:~# rsync -rlptogvR -e "ssh -l root" --numeric-ids "/home/geohei/" jw@192.168.1.174::QQQ/server1
...

Code: Select all

root@nas:/volume1# ls -l abc/
total 0
drwxrwxrwx+ 1 root root   8 Sep  4 16:27 @eaDir
d---------+ 1 root nobody 8 Sep  4 16:38 server1
... as opposed to (I left the -R option out) ...

Code: Select all

root@server1:~# rsync -rlptogv -e "ssh -l root" --numeric-ids "/home/geohei/" jw@192.168.1.174::QQQ/server1
...

Code: Select all

root@nas:/volume1# ls -l abc/
total 0
drwxrwxrwx+ 1 root root   8 Sep  4 16:27 @eaDir
drwxr-xr-x  1 1000 1000 108 Sep  2 19:53 server1
... I see that the permissions & uid:gid of server1 changes on the NAS. The rest of the files after server1 (same below for server2) have the correct source permissions & uid:gid (as desired).

Now ... I don't see why the -R option should change the permissions & uid:gid of directory server1 ?!?! Also, on the first test with server1 and -R option, I see all of a sudden ACLs on the NAS. Where do these come from? Also (2), gid becomes nobody (99).

I tested the same on server2. This one doesn't produce this behavior.

Code: Select all

geohei@server2:~$ rsync -rlptvogR -e "ssh -l root" --numeric-ids ... jw@fqdn_nas::QQQ/server2
...

Code: Select all

root@nas:/volume1# ls -ln abc/
total 0
drwxrwxrwx+ 1     0 0  8 Sep  4 16:27 @eaDir
drwx--x---  1 26766 4 98 Sep  4 16:30 server2

Code: Select all

geohei@server2:~$ rsync -rlptvog -e "ssh -l root" --numeric-ids ... jw@fqdn_nas::QQQ/server2
...

Code: Select all

root@nas:/volume1# ls -ln abc/
total 0
drwxrwxrwx+ 1     0 0  8 Sep  4 16:27 @eaDir
drwx--x---  1 26766 4 98 Sep  4 16:30 server2
rsync is complicated (and for me still mystery)!

nixjps
Apprentice
Apprentice
Posts: 98
Joined: Fri Jun 09, 2017 1:39 pm

Re: rsync issues and questions

Unread post by nixjps » Mon Sep 04, 2017 6:45 pm

geohei wrote:[...]
When I say ...

Code: Select all

root@server1:~# rsync -rlptogvR -e "ssh -l root" --numeric-ids "/home/geohei/" jw@192.168.1.174::QQQ/server1
...

Code: Select all

root@nas:/volume1# ls -l abc/
total 0
drwxrwxrwx+ 1 root root   8 Sep  4 16:27 @eaDir
d---------+ 1 root nobody 8 Sep  4 16:38 server1
Oops, the nobody is because we forgot to expand on /etc/rsyncd.conf. (good as it raises the question ;-]).
When you run the above rsync command, the daemon server will create folder server1. As you have a trailing slash in your source, server1 is at same level of the path to sync, hence there is not ownership/permissions to cascade.
Folder server1 will be owned by root, as for group.... well it's by default nobody.... For the latter we can change this by adding line "gid = root" in /etc/rsyncd.conf (or any other group that suits the need).
As you have -R, rsync will then create QQQ::server1/home (with expected perms/owner/group, QQQ:server1/home/geohei (with expected perms/owner/group) and then copy all files and folders of /home/geohei (sync its content)...

When you don't use -R, then you could expect the same kind of process as above, (and I think it does with more recent rsync version) but in fact it's slightly different....
rsync will create server1 as above, it will then sync ./ (that is /home/geohei) in QQQ::server1.... Hence server gets the ownership and permissions of /home/geohei....
(If you do not use the trailing slash it would have created will create a folder QQQ:geohei/server1, with correct permissions)

BTW, unless I'm wrong it's better to not use trailing slash in source path when you want to sync a tree.
geohei wrote: [...]
I tested the same on server2. This one doesn't produce this behavior.
The behavior of server1 which has an older version may have been changed.

I suggest you run both "non -R" command with -by adding one or two additonal "v" on your option and compare result.

Rgds,
DS916+ (8G) - DSM 6.1.3-15152u4 - ST8000VN0022-2EL112 x 3 - 1 SHR Disk Group - 2 volumes - Home Usage
DS216Play - DSM 6.1.3-15152u4 - ST4000DM000-1F2168 x 2 - Basic Disks - 2 Volumes - Off site backup of DS916+ and local browsing of Photos, Musics and Videos
DS916 and DS216Play MAN link (1Gb FFTH same ISP).
DS916 S2S -> DS216Play, HyperBackup of DS916 config & critical data to DS216Play. HyperBackup of DS216Play configuration and local data to DS916

geohei
Experienced
Experienced
Posts: 111
Joined: Wed Aug 02, 2017 10:58 am

Re: rsync issues and questions

Unread post by geohei » Wed Sep 06, 2017 5:36 pm

Ok. Thanks again!

server1 test ...

Success regarding server1 uid:gid root:nobody. Adding this in /etc/rsyncd.con did what you said. server1 uid:gid becomes root:root.

Also, it's all about permissions and uid:gid of directory server1 on destination. All downstream (to server1/*) files/folders have 100% correct source permissions & uid:gid.

I do need -R since I cascade different directories. Without the -R, the destination backup would be a mess! Regarding the source trailing slash, it has NO impact on server1 permissions/uid:gid if I have the -R option set. Without the -R option however, server1 permissions/uid:gid change indeed (as you announced).
nixjps wrote:BTW, unless I'm wrong it's better to not use trailing slash in source path when you want to sync a tree.
As I did yot see any change in behavior on the destination side, I decided to leave the trailing slash in the source to show that it's a directory and not a file I rsync. But if you tell me that functionality changes due to this, I will delete it of course.
nixjps wrote:I suggest you run both "non -R" command with -by adding one or two additonal "v" on your option and compare result.
I didn't even know rsync would take more than 1 -v :)

You mean I should add the optiions -b and -y?

Bottom line ... we're down to the permission of the destination server1 created by rsync. uid:gid are now correct. So we are getting closer every day.

Remains however the question about why rsync adds ACL permissions to server1.

... later ...

Code: Select all

root@nas:/volume1# cd abc/
root@nas:/volume1/abc# mkdir dir1
root@nas:/volume1/abc# ls -l
total 0
d---------+ 1 root root 0 Sep  6 18:28 dir1
drwxrwxrwx+ 1 root root 8 Sep  4 17:10 @eaDir
root@nas:/volume1/abc# cd ..
root@nas:/volume1# mkdir def
root@nas:/volume1# cd def
root@nas:/volume1/def# mkdir dir2
root@nas:/volume1/def# ls -l
total 0
drwxr-xr-x 1 root root 0 Sep  6 18:28 dir2
root@nas:/volume1/def# ls -l ..
total 0
d---------+ 1 root  root   20 Sep  6 18:28 abc
drwxr-xr-x  1 root  root    8 Sep  6 18:28 def
...
Directory abc was created via DSM. ACLs!
Directory dir1 was created inside abc via shell/mkdir. ACLs!
Directory def was created via DSM. ACLs!
Directory dir2 was created inside def via shell/mkdir. No ACLs!

Wild idea ... could it be that, due to the fact that directory abc was initially created via DSM, this makes that server1 also has ACLs while using the -R option?

However this doesn't explain why server2 doesn't have ACLs with the -R option.

nixjps
Apprentice
Apprentice
Posts: 98
Joined: Fri Jun 09, 2017 1:39 pm

Re: rsync issues and questions

Unread post by nixjps » Thu Sep 07, 2017 5:07 pm

Hi,
geohei wrote: [...]
I do need -R since I cascade different directories. Without the -R, the destination backup would be a mess! Regarding the source trailing slash, it has NO impact on server1 permissions/uid:gid if I have the -R option set. Without the -R option however, server1 permissions/uid:gid change indeed (as you announced).
[...]
Sure, I understand you need -R. I was not questioning that at all... Just highlighted the impact of using -R vs not using it on the permissions on folder server1/ (as well as when having a trailing /).
geohei wrote:
nixjps wrote:BTW, unless I'm wrong it's better to not use trailing slash in source path when you want to sync a tree.
As I did yot see any change in behavior on the destination side, I decided to leave the trailing slash in the source to show that it's a directory and not a file I rsync. But if you tell me that functionality changes due to this, I will delete it of course.
Well, for sure it has an impact. Unless i'm wrong, in source, a trailing slash tells rsync to sync the content of folder (and sub folder with -r) , when no trailing slash and source is a folder, rsync syncs folder (and sub folder with -r).
Actually, with -R, it may seem it has not significant impact on the tree in target (though we can see perms of server1 are handled slightly differently)

To be honest, I remember from old days that it had some undesired effects but I do not recall exactly which side effects.... Just googled.... See http://defindit.com/readme_files/rsync_backup.html (see comment ion point 1 and point 2b)...
geohei wrote:
nixjps wrote:I suggest you run both "non -R" command with -by adding one or two additonal "v" on your option and compare result.
I didn't even know rsync would take more than 1 -v :)
Yep... ;-D the more v you have the more verbose is the output ;-D
geohei wrote: You mean I should add the optiions -b and -y?
er.... no, no.... my bad.... I must have started writing "with -vvv" then change my mind to "by adding" and forgot to clean up the sentence ;-O...

I was suggesting you run the commands on both rsync client and add a few additional 'v' to increase "debug" output.
So rsync -avrR could be -vvv -arR...
Knowing that they do have different client rsync version, comparing "-v" results could be interesting...
However, I made a couple of tests yesterday using two different versions of rsync on client side and did not notice differences in behavior as far as server side (synology) is concerned. May be you testbed is different.

geohei wrote:
Bottom line ... we're down to the permission of the destination server1 created by rsync. uid:gid are now correct. So we are getting closer every day.
Permissions on destination folder/file is preserved when the folder/file is in the tree to copy.
The destination folder (QQQ:server1 and QQQ:server2) when it's not part of the tree is created with default system permissions.

(BTW, in rsync 3.0.9, before creating the top level destination directory, program saves umask value, sets umask to 0, creates the directory and sets back umask to original value. In more recent version it simply creates directory with default permission 0777, so process umask value is used)....)

On synology, it seems that that when using -R, the target directory inherits the default ACL permissions with or without trailing / in source. Same behavior when not using -R and no trailing / in source. When using -R and a trailing / in source, ACL is cleared and default 0777 permission is used. Makes sense to me as I believe its in fact driven by the client. See later why.

geohei wrote:
Remains however the question about why rsync adds ACL permissions to server1.
Actually, I believe that what is happening is not that rsync adds ACL permissions.... What happens is that it uses mkdir(3) with mode 0777 to create folder 'server?', that folder being in one that has ACL ans inheritance set.... So folder 'server?' inherits....
Question is in fact why does this not happen when we use -R and and a trailing / in source?.... I suspect that if we paused or killed the transfer just after creation, we would see that 'server?' inherits ACL....

When we wait until end of transmission permissions, ownership and group membership are set according to source (assuming -pog and user is root). As we are using a trailing slash, a chmod(3) is done on folder 'server1' with the permissions of source './'.... That clears ACLs.

I may be wrong, but this must be close to what is going on....
geohei wrote: ... later ...

Code: Select all

root@nas:/volume1# cd abc/
root@nas:/volume1/abc# mkdir dir1
root@nas:/volume1/abc# ls -l
total 0
d---------+ 1 root root 0 Sep  6 18:28 dir1
drwxrwxrwx+ 1 root root 8 Sep  4 17:10 @eaDir
root@nas:/volume1/abc# cd ..
root@nas:/volume1# mkdir def
root@nas:/volume1# cd def
root@nas:/volume1/def# mkdir dir2
root@nas:/volume1/def# ls -l
total 0
drwxr-xr-x 1 root root 0 Sep  6 18:28 dir2
root@nas:/volume1/def# ls -l ..
total 0
d---------+ 1 root  root   20 Sep  6 18:28 abc
drwxr-xr-x  1 root  root    8 Sep  6 18:28 def
...
Directory abc was created via DSM. ACLs!
Directory dir1 was created inside abc via shell/mkdir. ACLs!
Directory def was created via DSM. ACLs!
Directory dir2 was created inside def via shell/mkdir. No ACLs!

Wild idea ... could it be that, due to the fact that directory abc was initially created via DSM, this makes that server1 also has ACLs while using the -R option?
Not so wild.... Yes.... Correct.

BTW, you wrote "Directory def was created via DSM. ACLs!". I believe you meant with "shell/mkdir"... At least this is what the quote shows... that is.... abc, created with DSM, has ACL, so dir1 gets it too. While def created from shell in /volume1 has no ACL, hence dir2 has none too.
see synoacltool.
geohei wrote:
However this doesn't explain why server2 doesn't have ACLs with the -R option.
I would suggest you redo the test to make sure that behaviour is not as discussed above.

Cheers,
DS916+ (8G) - DSM 6.1.3-15152u4 - ST8000VN0022-2EL112 x 3 - 1 SHR Disk Group - 2 volumes - Home Usage
DS216Play - DSM 6.1.3-15152u4 - ST4000DM000-1F2168 x 2 - Basic Disks - 2 Volumes - Off site backup of DS916+ and local browsing of Photos, Musics and Videos
DS916 and DS216Play MAN link (1Gb FFTH same ISP).
DS916 S2S -> DS216Play, HyperBackup of DS916 config & critical data to DS216Play. HyperBackup of DS216Play configuration and local data to DS916

geohei
Experienced
Experienced
Posts: 111
Joined: Wed Aug 02, 2017 10:58 am

Re: rsync issues and questions

Unread post by geohei » Fri Sep 08, 2017 3:00 pm

Hi.
nixjps wrote: Well, for sure it has an impact. Unless i'm wrong, in source, a trailing slash tells rsync to sync the content of folder (and sub folder with -r) , when no trailing slash and source is a folder, rsync syncs folder (and sub folder with -r).

Actually, with -R, it may seem it has not significant impact on the tree in target (though we can see perms of server1 are handled slightly differently)

To be honest, I remember from old days that it had some undesired effects but I do not recall exactly which side effects.... Just googled.... See http://defindit.com/readme_files/rsync_backup.html (see comment ion point 1 and point 2b)...
I read all this (incl. your link) and tested.
So all you said above becomes true only as soon as the -R option is omitted.

With the -R option, there is no difference between both commands below (trailing slash in source is the difference):

Code: Select all

root@server1:~# rsync -rlptogvR -e 'ssh -l root' --numeric-ids "/home/geohei/" jw@192.168.1.174::QQQ/server1
...
root@server1:~# rsync -rlptogvR -e 'ssh -l root' --numeric-ids "/home/geohei" jw@192.168.1.174::QQQ/server1
...
Also ... whether I use the module QQQ or the path /volume1/abc doesn't matter.
Hence, for me, the trailing slash doesn't matter in the source since I use the -R option.
You agree?

Adding verbosity didn't really reveal any additional useful information regarding my directory "server1" ACL subject. But I keep the -vv(v) option in mind for later debugging.
nixjps wrote:
geohei wrote:Bottom line ... we're down to the permission of the destination server1 created by rsync. uid:gid are now correct. So we are getting closer every day.
Permissions on destination folder/file is preserved when the folder/file is in the tree to copy.
The destination folder (QQQ:server1 and QQQ:server2) when it's not part of the tree is created with default system permissions.

(BTW, in rsync 3.0.9, before creating the top level destination directory, program saves umask value, sets umask to 0, creates the directory and sets back umask to original value. In more recent version it simply creates directory with default permission 0777, so process umask value is used)....)

On synology, it seems that that when using -R, the target directory inherits the default ACL permissions with or without trailing / in source. Same behavior when not using -R and no trailing / in source. When using -R and a trailing / in source, ACL is cleared and default 0777 permission is used. Makes sense to me as I believe its in fact driven by the client. See later why.
But then we are down to the different behavior of destionation directories "server1" and "server2" of this posting:
See: https://forum.synology.com/enu/viewtopi ... 07#p498145
"server1" on destination has ACLs.
"server2" has no ACLs.
I don't see how this would be explained by the above.
nixjps wrote:
geohei wrote:Remains however the question about why rsync adds ACL permissions to server1.
Actually, I believe that what is happening is not that rsync adds ACL permissions.... What happens is that it uses mkdir(3) with mode 0777 to create folder 'server?', that folder being in one that has ACL ans inheritance set.... So folder 'server?' inherits....
Question is in fact why does this not happen when we use -R and and a trailing / in source?.... I suspect that if we paused or killed the transfer just after creation, we would see that 'server?' inherits ACL....

When we wait until end of transmission permissions, ownership and group membership are set according to source (assuming -pog and user is root). As we are using a trailing slash, a chmod(3) is done on folder 'server1' with the permissions of source './'.... That clears ACLs.

I may be wrong, but this must be close to what is going on....
I read, reread and rereread what you wrote, but as far as I understood, all this still doesn't explain why in the tests above, server1 behaves different than server2 (both with the -R option) in terms of ACLs.
nixjps wrote:
geohei wrote:...
Directory abc was created via DSM. ACLs!
Directory dir1 was created inside abc via shell/mkdir. ACLs!
Directory def was created via DSM. ACLs!
Directory dir2 was created inside def via shell/mkdir. No ACLs!

Wild idea ... could it be that, due to the fact that directory abc was initially created via DSM, this makes that server1 also has ACLs while using the -R option?
Not so wild.... Yes.... Correct.

BTW, you wrote "Directory def was created via DSM. ACLs!". I believe you meant with "shell/mkdir"... At least this is what the quote shows... that is.... abc, created with DSM, has ACL, so dir1 gets it too.
...
Yes, you are right of course. Copy/Paste mistake from my side.
You really track everything! (scary :) )
nixjps wrote:I would suggest you redo the test to make sure that behaviour is not as discussed above.
Sorry ... which one do you mean.
Hint is sufficient.

I will reread your posting tomorrow again. I have the feeling I missed something.

Thanks,

nixjps
Apprentice
Apprentice
Posts: 98
Joined: Fri Jun 09, 2017 1:39 pm

Re: rsync issues and questions

Unread post by nixjps » Sat Sep 09, 2017 1:33 am

Hi,
geohei wrote: [...]
So all you said above becomes true only as soon as the -R option is omitted.
With the -R option, there is no difference between both commands below (trailing slash in source is the difference):

Code: Select all

root@server1:~# rsync -rlptogvR -e 'ssh -l root' --numeric-ids "/home/geohei/" jw@192.168.1.174::QQQ/server1
...
root@server1:~# rsync -rlptogvR -e 'ssh -l root' --numeric-ids "/home/geohei" jw@192.168.1.174::QQQ/server1
...
Correct. Though I would recommend taking the habit of using a trailing '/' only when required to be consistent with rsync with no -R option where it matters.
geohei wrote: Also ... whether I use the module QQQ or the path /volume1/abc doesn't matter.
Hence, for me, the trailing slash doesn't matter in the source since I use the -R option.
You agree?
Correct again.
Matters however to explain some behavior you mentioned in https://forum.synology.com/enu/viewtopi ... 07#p498145 ;-D
geohei wrote:
nixjps wrote: Permissions on destination folder/file is preserved when the folder/file is in the tree to copy.
The destination folder (QQQ:server1 and QQQ:server2) when it's not part of the tree is created with default system permissions.

(BTW, in rsync 3.0.9, before creating the top level destination directory, program saves umask value, sets umask to 0, creates the directory and sets back umask to original value. In more recent version it simply creates directory with default permission 0777, so process umask value is used)....)

On synology, it seems that that when using -R, the target directory inherits the default ACL permissions with or without trailing / in source. Same behavior when not using -R and no trailing / in source. When using -R and a trailing / in source, ACL is cleared and default 0777 permission is used. Makes sense to me as I believe its in fact driven by the client. See later why.
But then we are down to the different behavior of destionation directories "server1" and "server2" of this posting:
See: https://forum.synology.com/enu/viewtopi ... 07#p498145
"server1" on destination has ACLs.
"server2" has no ACLs.
I don't see how this would be explained by the above.
nixjps wrote:
geohei wrote:Remains however the question about why rsync adds ACL permissions to server1.
Actually, I believe that what is happening is not that rsync adds ACL permissions.... What happens is that it uses mkdir(3) with mode 0777 to create folder 'server?', that folder being in one that has ACL ans inheritance set.... So folder 'server?' inherits....
Question is in fact why does this not happen when we use -R and and a trailing / in source?.... I suspect that if we paused or killed the transfer just after creation, we would see that 'server?' inherits ACL....

When we wait until end of transmission permissions, ownership and group membership are set according to source (assuming -pog and user is root). As we are using a trailing slash, a chmod(3) is done on folder 'server1' with the permissions of source './'.... That clears ACLs.

I may be wrong, but this must be close to what is going on....
I read, reread and rereread what you wrote, but as far as I understood, all this still doesn't explain why in the tests above, server1 behaves different than server2 (both with the -R option) in terms of ACLs.
I believe it does. ;-D. I give another look at your sequence in the post you referred to. I think that what has happened is that you might have kept folder server2 between testing sequences ... Hence some commands triggered a mkdir from server while other did not not (because already existing folder)...

According to your test you first did:
- root@server1:~# rsync -rlptogvR -e "ssh -l root" --numeric-ids "/home/geohei/" jw@192.168.1.174::QQQ/server1
As per rules discussed above. server1 is created in module's QQQ folder (which has ACL) with default permissions (mkdir()) and ownership/group membership as per your /etc/rsyncd.conf
Hence you get "d---------+ 1 root nobody 8 Sep 4 16:38 server1"
Then you run same command without -R:
- root@server1:~# rsync -rlptogv -e "ssh -l root" --numeric-ids "/home/geohei/" jw@192.168.1.174::QQQ/server1
At this stage whether you had deleted server1 or not has no impacts. Indeed as per rules discussed above, because of the trailing /, you are syncing content of geohei (king of ./) into server1 so at the end of the transfer rsync server will explicitly set permission on server1 hence will clear ACLs.
ls gave "drwxr-xr-x 1 1000 1000 108 Sep 2 19:53 server1", which I bet is the permission, ownership and group membership of /home/geohei

Then you did tests for server2.
You wrote you run:
- geohei@server2:~$ rsync -rlptvogR -e "ssh -l root" --numeric-ids ... jw@fqdn_nas::QQQ/server2
And result being "drwx--x--- 1 26766 4 98 Sep 4 16:30 server2"
Given folder's owner, I suspect you had run just before rsync -rlptvog, which due to trailing slash created folder server2 with owner 26766. Otherwise, assuming server2 did not exists, you would have had ownership rsyncd.conf's uid/gid and system default permissions due to the mkdir(3) (with ACLs)....

geohei wrote: [...]
nixjps wrote:I would suggest you redo the test to make sure that behaviour is not as discussed above.
Sorry ... which one do you mean.
The sequence in https://forum.synology.com/enu/viewtopi ... 52#p498145 making sure server{1|2} are deleted between transfers.

I think we are close to have addressed the questions and uncertainties. Once we have, we can post a summary to close the thread. ;-D. What do you think?

PS: Have had a chance to test the /etc/sudoers suggestion? That would allow running rsync as root (--rsync-path "sudo rsync") from user jw@synologyDSM without exposing root account through ssh.

Cheers,
DS916+ (8G) - DSM 6.1.3-15152u4 - ST8000VN0022-2EL112 x 3 - 1 SHR Disk Group - 2 volumes - Home Usage
DS216Play - DSM 6.1.3-15152u4 - ST4000DM000-1F2168 x 2 - Basic Disks - 2 Volumes - Off site backup of DS916+ and local browsing of Photos, Musics and Videos
DS916 and DS216Play MAN link (1Gb FFTH same ISP).
DS916 S2S -> DS216Play, HyperBackup of DS916 config & critical data to DS216Play. HyperBackup of DS216Play configuration and local data to DS916

Locked

Return to “System Managment Mods”