I have a server configured to run rsync as demon /etc/rsyncd.conf file:

log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock

   path = /home/user/work
   comment = User's Documents folder
   uid = user
   gid = user
   read only = no
   auth users = user
   secrets file = /etc/rsyncd.secrets

/etc/rsyncd.secrets file:


on the client side I run:

rsync my_file user@ip_address::documents

and I receive the following error:

@ERROR: auth failed on module documents
rsync error: error starting client-server protocol (code 5) at main.c(1524) [sender=3.0.7]

On the server I have a root user named user with different password. On the client side I tried both passwords with the same results.

What I'm doing wrong?

  • In order to use rsync as a deamon I use [documents] path = /home/user/work comment = User's Documents folder read only = no . Without a user and authentication. – telebog Mar 1 '11 at 9:55
  • Is there a specific reason you are wanting to use rsyncd? It is far easier and more secure using rsync via ssh like this: rsync -avP /source user@host:/destination – UtahJarhead Oct 16 '12 at 18:59
  • @UtahJarhead I don't know about the OP, but in my case, transferring 5-10 2TB chunks compressed of files across a stub network means that I don't care about the security of the transfer. I want every available byte going down the wire. Extra protocol overhead and encryption of traffic that I don't need. A few kps lost means a few hours on the far end of the job. rsync generates an on the fly checksum that validates the transfer which is separate from the -c option for comparing existing files. – Rowan Hawkins Jun 7 '17 at 16:05
  • @RowanHawkins Quite right, mate! That's about the only reason to use rsyncd over rsync+ssh. However, the overhead from ssh likely won't affect the transfer speed unless weak CPUs are involved. Encryption + weak CPUs = bleh. – UtahJarhead Jun 15 '17 at 20:24

I get the same error and when Im looking in the log file I get this message:

secrets file must not be other-accessible

So probably you have to change the permission of the file.

  • chmod -o /etc/rsyncd.conf – Neil McGuigan Oct 19 '17 at 0:06

Look in /var/log/rsyncd.log. Maybe the perms in your "/etc/rsyncd.secrets " file are too wide.

  • 2011/03/01 11:49:07 [13367] connect from user2.local ( 2011/03/01 11:49:10 [13367] auth failed on module work from user2.local ( unauthorized user in /etc/rsyncd.secrets file I added: user2:passwd user2.local:passwd But same result. – telebog Mar 1 '11 at 9:52

The answer by schemanen is correct, however you have the option to disable strict modes in rsyncd.conf without removing read permissions from the secrets file from other users.

in your /etc/rsyncd.conf add:

strict modes = false

and finally restart the rsync daemon.


The problem could be a space in front of the password:

  • Wrong: user: password

  • Right: user:password

As the others said, you also have to make sure the permissions are set correctly (chmod o-rwx) but this is a different issue.


I removed the entry from rsync.conf for "auth user = user", and restarted rsyncd. Use of "auth" forces the challenge password to be entered despite use of a secrets file. And, though I had the same password in user/password pair in the secrets file, it still failed with the error you indicated. Removing "auth user" was my solution. The permissions on my secrets file: "500". Cronjob on client executed as root.


One more thing to look for, and this is what was killing my setup.

DO NOT use :rw after the user name in the auth users line unless your version of rsync supports it. The man page for 3.1.2 I found at download.samba.org has the :rw option for users in the 'auth users' line, however the 3.0.9 version that I had on an older Mint doesn't yet have :rw. I wasted a lot of time trying to get rsyncd to work - took off the ':rw' and bang! It worked perfectly. (Of course, a better solution would be to update that computer - which is planned..)

Also, in my case, if I didn't have the auth users line, no password would be asked for - which was not acceptable for my setup. I'm curious as to how it worked for @mthebie99 to get the password prompt. Unless, of course, @mthebie99 was using a version where it works right (or at least as I would have expected).

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.