5

This is a bit long winded but I want to give as much information as I can. I have a Synology NAS running DSM 7.2.2:

steve@NAS:/volume1/docker/backuppc-mdns$ cat /proc/sys/kernel/syno_hw_version DS223j 
steve@NAS:/volume1/docker/backuppc-mdns$ head -n 5 /etc/VERSION majorversion="7" minorversion="2" major="7" minor="2" micro="2

and I created a backuppc docker on the NAS which works fine my hosts.

I want to backup the files that I used to create the docker.

My NAS is known as nas.local to backuppc and I have a user, steve, on nas.local that has Administrator privilege. I've set up ssh keys and I can ssh from backuppc.local to nas.local as steve. I can use rsync over ssh with this from backuppc:

$ rsync -e "ssh -p 2222" --list-only [email protected]:/volume1/docker/backuppc-mdns/

However I need to run sudo rsync since some of the files are owned by bcakuppc and some be root. This:

$ rsync -e "ssh -p 2222" --rsync-path="sudo /usr/bin/rsync" --list-only [email protected]:/volume1/docker/backuppc-mdns/ ERROR: user has disabled/expired rsync error: wrong password (code 44) at main.c(819) [sender=3.1.2]

fails and:

$ sudo journalctl -u sshd -f Sep 01 11:43:43 NAS sshd[30067]: Accepted publickey for steve from 192.168.4.2 port 39428 ssh2: RSA SHA256:3CxLZHnwawsUGT2ctsBknhJNISb/8amFcqEYjWFp03c Sep 01 11:43:43 NAS sshd[30067]: pam_unix(sshd:session): session opened for user steve by (uid=0) Sep 01 11:43:43 NAS sudo[30071]: steve : PWD=/volume1/homes/steve ; USER=root ; COMMAND=/usr/bin/rsync --server --sender -de.LsfxCIvu --list-only . /volume1/docker/backuppc-mdns/ Sep 01 11:43:43 NAS sudo[30071]: pam_unix(sudo:session): session opened for user root by (uid=1026) Sep 01 11:43:43 NAS rsync[30072]: User [admin] now is disabled/expired. Sep 01 11:43:43 NAS rsync[30072]: root has disabled/expired Sep 01 11:43:43 NAS sshd[30067]: pam_unix(sshd:session): session closed for user steve Sep 01 11:43:43 NAS sudo[30071]: pam_unix(sudo:session): session closed for user root

User steve is in the sudoers file:

steve@NAS:/volume1/docker/backuppc-mdns$ sudo grep steve /etc/sudoers \# Allow user steve to run rsync with no password steve ALL=(ALL) NOPASSWD: /usr/local/bin/sudo_rsync_wrapper.sh * steve ALL=(ALL) NOPASSWD: /bin/rsync steve ALL=(ALL) NOPASSWD: /usr/bin/rsync

So there is something blocking rsync from running as root. Is there a way to get this working? I'm also curious aabout why there are two identical binaries for rsync. One in /bin and one in /usr/bin. Steve

Improve this question
1
  • 1
    Your /bin is likely a symlink to usr/bin. Check with: "ls -l -d /bin". Commented Sep 6 at 6:18

1 Answer 1

Reset to default
4

DSM can be a bit "funny", I had this issue before and fixed it by following this

Generally, rsync'ing as root is bad. However, if you're pulling backups, it's the only way to read all files and preserve their permissions (necessary if you're using the NAS in a UNIX-like way). To do this, the above directions work, but with one issue. On rsync, you'll get the error "ERROR: user has disabled/expired". This is coming from the rsync layer, not ssh, and it's because the root account is "disabled".

Surprisingly, this is fixed from the GUI of Synology – find the account called "admin" and enable it, and that will fix rsync-as-root.

Regarding your question about the two binaries, /bin/rsync is most likely a symbolic link. For more details, you can check this

Improve this answer
7
  • 2
    OK, I've enabled the admin account. We'll see what happens tonight. Commented Sep 5 at 16:35
  • Regarding the rsync binaries, neither one looks like a symbolic link. They look identical: steve@NAS:/volume1/docker/backuppc-mdns$ ls -l /bin/rsync /usr/bin/rsync -rwsr-xr-x 1 root root 650064 Dec 2 2022 /bin/rsync -rwsr-xr-x 1 root root 650064 Dec 2 2022 /usr/bin/rsync steve@NAS:/volume1/docker/backuppc-mdns$ md5sum /bin/rsync /usr/bin/rsync 76376652412cc305f91049436e09d986 /bin/rsync 76376652412cc305f91049436e09d986 /usr/bin/rsync Commented Sep 5 at 18:58
  • I'm surprised. They might be identical copies or they might be hard-linked. Try running stat on them; if the inode numbers match, they are hard links. Also, I realized that Synology let the setuid bit on rsync. Why not, but keep in mind this is a security flaw and can expose your system. Commented Sep 5 at 20:04
  • I've been trying a couple of things and so far no luck. When I enabled the admin account the error 44 went away but then I started getting error 52 - rsync service disabled even though the rsync service and account were enabled. The I tried adding the admin user to the list of rsync users but that had no effect. Then I changed from using sudo /bin/rsync to just /bin/rsync and that got rid of the error 52 but of course now I get error 13 on files I don't own which was the whole point of running rsync sudo. Aargh! Commented Sep 9 at 16:40
  • The two rsync files do indeed have the same inode number. There are also two ssh binaries and they also share an inode number. Commented Sep 9 at 16:42

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.