I have a D-Link DNS-320 and I've installed FFP and I'm trying to get rsync running on it.

So far I've got the daemon up and running and I've defined a module in my rsyncd.conf like so:

max connections = 10
secrets file = /ffp/etc/rsyncd.secret

use chroot = false
read only = no
list = true
strict modes = false
#hosts deny = *
timeout = 600
dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz *.mkv *.avi *.mpg *.jpg *.rar
pid file = /var/run/rsyncd.pid
reverse lookup = no

hosts allow = *
read only = false
gid = allaccount
uid = nobody
auth users = greg
path = /mnt/HD/HD_a2/rsync
comment = Fish
list = yes

/mnt/HD/HD_a2 is the internal disk and /mnt/HD/HD_a2/rsync exists:

root@nas:/mnt/HD/HD_a2/rsync# pwd  

with the following permissions:

root@nas:/mnt/HD/HD_a2# ls -la
total 154589
drwxrwxrwx 23 root   root            4096 Oct  2 19:44 .
drwxr-xr-x  3 root   root            1024 Oct  2 17:20 ..
drwxrwxrwx  4 root   root            4096 Dec 29  2013 Ajaxpf
drwxrwxrwx 21 nobody allaccount      4096 Oct  2 15:45 NAS
dr-xr-xr-x  4 root   root            4096 Sep 24 17:45 Public
drwxr-xr-x  3 root   root            4096 Sep 24 17:45 Users
drwxr-xr-x 17 root   root            4096 Aug 27 14:11 ffp
-rw-r--r--  1 root   root            1117 Oct  2 17:20 ffp.log
-rwxr-xr-x  1 root   root            1942 Sep 23 17:29 fun_plug
drwxr-xr-x  2 root   root            4096 Jul 15  2012 logs
drwxrwxrwx  2 nobody allaccount      4096 Oct  2 21:09 rsync

I have the user greg defined in my rsync.secret file and I can successfully connect from my (Windows) client and list the module:

C:\Batch\rsync> rsync greg@nas::  
root            Fish

However; When I try to send a file I get @ERROR: chdir failed:

C:\Batch\rsync> rsync -vvvv SRC test.txt greg@nas::root/test.txt  
opening tcp connection to nas port 873  
Connected to nas (  
note: iconv_open("UTF-8", "UTF-8") succeeded.  
sending daemon args: --server -vvvve.Lsf . root/test.txt  
@ERROR: chdir failed  
[sender] _exit_cleanup(code=5, file=/usr/src/ports/rsync/rsync-3.0.9-1/src/rsync-3.0.9/main.c, line=1516): entered  
rsync error: error starting client-server protocol (code 5) at /usr/src/ports/rsync/rsync-3.0.9-1/src/rsync-3.0.9/main.c  
(1516) [sender=3.0.9]  
[sender] _exit_cleanup(code=5, file=/usr/src/ports/rsync/rsync-3.0.9-1/src/rsync-3.0.9/main.c, line=1516): about to call

I'm using Cygwin rsync version 3.0.9 on the client and rsync version 3.1.0 on the server.

On the server, rsync is running as root:

root@nas:/mnt/HD/HD_a2# ps aux | grep rsync  
root     10074  0.0  0.3   1996   376 ?        Ss   21:57   0:00 /ffp/bin/rsync --daemon --config=/ffp/etc/rsyncd.conf --log-file=/var/log/rsync.log --ipv4 -vvvv

Why is chdir failing?

root can write to /mnt/HD/HD_a2/rsync:

root@nas:/mnt/HD/HD_a2/rsync# touch /mnt/HD/HD_a2/rsync/touch  
root@nas:/mnt/HD/HD_a2/rsync# ls -la  
total 8  
drwxrwxrwx  2 nobody allaccount 4096 Oct  2 22:21 .  
drwxrwxrwx 23 root   root       4096 Oct  2 19:44 ..    
-rw-r--r--  1 root   root          0 Oct  2 22:21 touch  

and rsync is running as root.

There's nothing useful in the log on the server:

2014/10/02 22:19:35 [10391] rsyncd version 3.1.0 starting, listening on port 873  
2014/10/02 22:19:41 [10394] connect from UNDETERMINED (  

So why is chdir failing? or how can I diagnose the problem further?


Regarding this being a duplicate of Configuring anonymous rsync daemon but the solutions pertained to SELinux being the issue. The DNS-320 runs an embedded, slimmed down version of Linux, which does not include SELinux's getenforce and setenforce commands, so if it is this, as suggested in the comments, how can I rectify it?

As these tools aren't available, what else could it be?

  • I had a similar issue and resolved it by disabeling SELinux (CentOS 7.2) -- yes, it's an old question but first hit on google for this error message. – Peter Schneider Aug 29 '16 at 9:15

I just ran in to this very issue on a QNAP device with this error;

ERROR: chdir failed
rsync error: error starting client-server protocol (code 5) at main.c(2547) [Receiver=3.0.7]

I solved it in a strange way by editing the rsync.conf file to

use chroot = true

Once the initial sync finished I set it back to

use chroot = false

And now it works.

| improve this answer | |
  • I'll never know as I got rid of the 320 a while ago. Hopefully this will be useful to someone. – Greg B Mar 16 '17 at 8:20

This could be an SELinux issue, it needs to know that the folder can be used by the rsync daemon. Let's consider an example, to rsync the following folder: /home/myuser/ftp

The following commands need to be run to set the correct SELinux context:

semanage fcontext -a -t rsync_data_t '/home/myuser(/.*)?'
restorecon -Rv '/home/myuser'
setsebool -P rsync_client on

Strangely enough, I noticed the parent folder must be labelled, hence why the labelling is done on /home/myuser instead of /home/myuser/ftp. Restricting to the ftp subfolder is simply done in the rsync daemon configuration.

You can check the SELinux labelling by running:

ls -Z /home/myuser

An interesting article about why combining chroot and SELinux is a good idea: http://blog.siphos.be/2012/04/why-both-chroot-and-selinux/

| 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.