I'm using rsync to repeatedly send a folder from source to destination. When using a straight bash command, it prompts for a password. In order to prevent the prompting of a password, I've made a simple cpp program that calls a bash script of rsync to repeatedly send the folder to the destination by doing fork and exec. I tried this answer, but it returns an error:

sudo rsync $args --password-file=rsync_pass -avz /home/user/folder/checkpoints/$1 secondaryvm@192.xxx.xxx.xxx::checkpoints/$1

rsync: failed to connect to 192.xxx.xxx.xxx (192.xxx.xxx.xxx): Connection refused (111)
rsync error: error in socket IO (code 10) at clientserver.c(127) [sender=3.1.3]

Note: I only want to use the --password-file option

I have checked that the rsync daemon is running on the destination side by running the command: sudo systemctl status rsync. Here's my rsyncd.conf

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

path = /home/public_rsync
comment = RSYNC FILES
read only = true
timeout = 300

How do I get this working?

  • You could use public key authentication if you don't want to enter a password, no need for a daemon. Edit your question and add your /etc/rsyncd.conf. Are auth users and secrets file defined and properly setup? – Freddy Oct 30 '20 at 8:02
  • The connection is being refused. This means either that the service is not running (on the standard port), or that there is a firewall somewhere on or between client and server rejecting such connections. – roaima Oct 30 '20 at 8:22
  • @Freddy where are these auth users and secrets file present? – y_159 Oct 30 '20 at 9:31
  • @roaima how can i check that? – y_159 Oct 30 '20 at 9:31
  • @roaima sudo systemctl status rsync on backup side – y_159 Oct 30 '20 at 10:28

The connection was refused because you were using a non-standard rsync port, see the comments by user roaima.

For simplicity, I expect user public_rsync with home directory /home/public_rsync exists on the destination host (192.xxx.xxx.xxx, where the daemon is running) and the service is not blocked by your firewall.

Start with this sample /etc/rsyncd.conf (passwords are enabled later):

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

path = /home/public_rsync/checkpoints
comment = RSYNC FILES
read only = false
uid = public_rsync
gid = public_rsync
#auth users = secondaryvm
#secrets file = /etc/rsyncd.secrets
timeout = 300


  • remove port = 12000 to use default port 873
  • change module name from [files] to [checkpoints]
  • change the path to the module directory to /home/public_rsync/checkpoints
  • change read only = true to false to be able to push files to the server
  • add uid / gid to use this username / group when transferring files

Then restart the server:

sudo systemctl restart rsync

1. Test rsync on the destination host as user public_rsync

  1. List all listable modules with rsync localhost::, it should return the module name and the description:

    public_rsync@192.xxx.xxx.xxx:~$ rsync localhost::
    checkpoints      RSYNC FILES
  2. Create directory checkpoints and a test file in this directory:

    public_rsync@192.xxx.xxx.xxx:~$ mkdir ~/checkpoints
    public_rsync@192.xxx.xxx.xxx:~$ echo helloworld > ~/checkpoints/helloworld.txt
  3. List all files of our module:

    public_rsync@192.xxx.xxx.xxx:~$ rsync localhost::checkpoints
    drwxrwxr-x          4,096 2020/10/30 18:26:01 .
    -rw-rw-r--             11 2020/10/30 18:26:01 helloworld.txt

2. Test rsync from the source host, make sure pull/push are working

  1. Test pull:

    $ rsync 192.xxx.xxx.xxx::checkpoints/helloworld.txt /tmp/
    $ cat /tmp/helloworld.txt
  2. Test push:

    $ rsync /tmp/helloworld.txt 192.xxx.xxx.xxx::checkpoints/helloworld_push.txt
  3. List files of module checkpoints again:

    $ rsync 192.xxx.xxx.xxx::checkpoints
    drwxrwxr-x          4,096 2020/10/30 18:29:06 .
    -rw-rw-r--             11 2020/10/30 18:26:01 helloworld.txt
    -rw-r--r--             11 2020/10/30 18:29:06 helloworld_push.txt

3. Enable authentication

Now that we know rsync works as expected, enable authentication on the destination host:

  1. Create text file /etc/rsyncd.secrets with username and password for user secondaryvm (the username is arbitrary, no user account needed):

    user@192.xxx.xxx.xxx:~$ sudo tee /etc/rsyncd.secrets > /dev/null <<'EOF'
    user@192.xxx.xxx.xxx:~$ sudo chmod 600 /etc/rsyncd.secrets
  2. Uncomment auth users and secrets file in /etc/rsyncd.conf, restart the server:

    user@192.xxx.xxx.xxx:~$ sudo systemctl restart rsync

4. Test authentication (from source host)

Connecting without credentials should not be possibly any more, you're supposed to enter a password:

$ rsync 192.xxx.xxx.xxx::checkpoints
@ERROR: auth failed on module checkpoints
rsync error: error starting client-server protocol (code 5) at main.c(1675) [Receiver=3.1.3]

Provide username and password for the connection, e.g.

$ echo '12345' > rsync_pass
$ chmod 600 rsync_pass
$ rsync --password-file=rsync_pass secondaryvm@192.xxx.xxx.xxx::checkpoints

If anything doesn't work, add verbosity with option -v and check the daemon log /var/log/rsync.log.

  • sorry i didn't checked this for some days. I followed the public key authentication answers on some pages. But what is happening now is it is unable to send some files which are permission protected. and throws this error: rsync: send_files failed to open "/home/usr/...../checkpoints/246/descriptors.json": Permission denied (13) – y_159 Nov 4 '20 at 12:28
  • public/private key process doesn't require passwords for transmission. but for these files it requires sudo and requires user to input password of destination – y_159 Nov 4 '20 at 12:30
  • Make sure that the files are readable by the rsync user (you could use a group for that), directories should also have the executable bit set. – Freddy Nov 4 '20 at 13:15
  • do you mean to say something like creating a group of users on the directory? What my scenario is there's repeatedly some folders are added into a directory, and i've to repeatedly send those folders to backup. – y_159 Nov 4 '20 at 13:37
  • That was the idea, but if the files in that directory belong to different users/groups that doesn't make sense. You could create an entry in your /etc/sudoers file to call your script with passwordless sudo, see unix.stackexchange.com/a/229653/332764 for an example and replace username/path to the script. Or create a script with passwordless sudo to change ownership/permissions on the files before you call your sync script as normal user. Use public key authentication or the version with password file from my answer. – Freddy Nov 4 '20 at 23:14

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.