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 [email protected]::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, 2020 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. Oct 30, 2020 at 8:22
  • @Freddy where are these auth users and secrets file present?
    – y_159
    Oct 30, 2020 at 9:31
  • @roaima how can i check that?
    – y_159
    Oct 30, 2020 at 9:31
  • @roaima sudo systemctl status rsync on backup side
    – y_159
    Oct 30, 2020 at 10:28

1 Answer 1


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:

    [email protected]:~$ rsync localhost::
    checkpoints      RSYNC FILES
  2. Create directory checkpoints and a test file in this directory:

    [email protected]:~$ mkdir ~/checkpoints
    [email protected]:~$ echo helloworld > ~/checkpoints/helloworld.txt
  3. List all files of our module:

    [email protected]:~$ 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):

    [email protected]:~$ sudo tee /etc/rsyncd.secrets > /dev/null <<'EOF'
    [email protected]:~$ sudo chmod 600 /etc/rsyncd.secrets
  2. Uncomment auth users and secrets file in /etc/rsyncd.conf, restart the server:

    [email protected]:~$ 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 [email protected]::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, 2020 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, 2020 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, 2020 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, 2020 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, 2020 at 23:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .