I have set up a small 1TB NAS appliance, now running on OpenWRT, to back-up files from a small 500Gb drive inside my Devuan Linux box holding all my Timeshift and BackInTime snapshots.

The NAS's specs -800MHz APM82181/256MB RAM- require avoiding the use of ssh or wait ages for a job to complete at 7.50MiB/s max, in spite of both ends having GbE ports negotiating at 1000M.

Happens that ssh beats this hardware to death with an almost constant 100% CPU load, mostly due to encryption, so it is not an viable option.

All this is done within a local network with no access from the ouside and I am the only user, so the lack of encryption is not an issue.

With that in mind, I had no choice but to use rsync as a daemon at the NAS end which would get me at least 3.5/4.0 times the throughput I can get with ssh.

The problem is that I am getting an error I cannot find a solution to.

:~$ rsync -av --progress /media/stuff/firefox.oldfile  rsync://groucho@
sending incremental file list
     85,812,416 100%   28.23MB/s    0:00:02 (xfr#1, to-chk=0/1)
rsync: [receiver] mkstemp "/.firefox.oldfile.hiOlHH" (in stuff) failed: Permission denied (13)

sent 85,833,480 bytes  received 142 bytes  24,523,892.00 bytes/sec
total size is 85,812,416  speedup is 1.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1207) [sender=3.1.3]

The good news is that 28.23MB/s is (apparently) obtainable. =^)

I have read that this is a permission issue originating in rsync not being able to write the temporary file /.firefox.oldfile.dMAADG to the destination folder /mnt/sda3/stuff.

The log file adds nothing to the terminal printout:

root@OpenWrt:~# cat /var/log/rsyncd.log
[2726] connect from UNDETERMINED (
[2726] rsync allowed access on module stuff from UNDETERMINED (
[2726] rsync to stuff/ from UNDETERMINED (
[2726] receiving file list
[2726] rsync: [receiver] mkstemp "/.firefox.oldfile.dMAADG" (in stuff) failed: Permission denied (13)

I think my rsyncd.conf file is correct:

:/etc$ cat /etc/rsyncd.conf
# /etc/rsyncd.conf
# minimal configuration for rsync daemon
# -----------------------
# begin global parameters 

gid = *
use chroot = true
max connections = 1
pid file = /var/run/rsyncd.pid
log file = /var/log/rsyncd.log
read only = false
reverse lookup = no
exclude = lost+found
timeout = 180

hosts allow =  # use after everything is working properly
# port =                   # set other than default 873
# socket options =
# ignore nonreadable = 
# dont compress   = *.gz *.tgz *.zip *.z *.Z *.rpm *.deb *.bz2 

# end global parameters 
# ---------------------------
# begin module parameters

# shared folder for testing
path = /mnt/sda3
read only = false
# comment =

# shared folder for stuff
path = /mnt/sda3
read only = false
# comment =

# shared folder for bkups
path = /mnt/sda3
read only = false
# comment =

The ownership of the destination directories is correct as far as I can make out:

:~$ ls -l /mnt/sda3
drwxrwxrwx    4 groucho  groucho       4096 Apr 25 19:03 bkups
drwxrwxrwx    2 groucho  groucho       4096 Apr 29 18:47 stuff
drwxrwxrwx    2 groucho  groucho       4096 Apr 28 17:53 testdir
:~$ ls -l /mnt

I've been at this for a couple of days now, to no avail.

I'd appreciate it if someone could shed some light on this for me.

Thanks in advance,


  • Is groucho the NAS? So you're pushing a backup to the NAS from your client, yes?
    – roaima
    Apr 30 at 16:40

1 Answer 1


Your paths are missing the lowest level. For example:

path = /mnt/sda3
read only = false

This defines a share called stuff with a root of /mnt/sda3. I would imagine that /mnt/sda3 itself is not writable by your rsyncd user, and based on the directory listing you've give us I would say this isn't what you're intending.

Instead, you should actually specify the complete path.

    path = /mnt/sda3/stuff
    read only = false
    fake user = yes

I have included the fake user setting here, so that user, group, and permissions details can be captured even through the rsyncd daemon user (probably) isn't root.

I usually have these options, many of which can go in the global section:

    comment = Backup space for stuff
    path = /mnt/sda3/stuff
    hosts allow = ...
    auth users = *
    secrets file = /etc/rsyncd.secrets

    use chroot = yes
    read only = no
    list = yes
    strict modes = yes
    ignore errors = no
    ignore nonreadable = no
    fake super = yes
    transfer logging = no
    timeout = 600
    refuse options = delete
    dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz *.vib *.vbk
  • Linux box => groucho@devuan; NAS => groucho@openwrt - Backing up (push) from box to NAS. You're right: groucho@OpenWrt:~$ touch /mnt/sda3/test1.txt -> touch: /mnt/sda3/test1.txt: Permission denied - I'll check all that. THXS
    – Groucho
    Apr 30 at 20:55
  • Worked a charm, remmed 'auth users' and 'secrets file' for the time being - Understand that the proper 'socket options' can speed up transfers. Is that so? THXS
    – Groucho
    Apr 30 at 21:28
  • No need to play with socket options. These days they're mostly self-adjusting so unless you have a very very specific requirement you might as well let the system worry about it for you
    – roaima
    May 1 at 7:26
  • Quite right. Found a snippet (very old post) on-line and tried wide range of values for --sockopts=SO_SNDBUF=n,SO_RCVBUF=n, always within box's parameters with no effect. | Still some issues: 1. had to rem "fake user = yes" as log said Unknown Parameter encountered - is it needed/how to fix? | 2. terminal printout says rsync: [generator] failed to set times on "/." (in stuff): Operation not permitted (1) | 3. --exclude=/lost+found seems to work only from the cmd line. Can it be set as a global parameter? THXS
    – Groucho
    May 1 at 11:45
  • You really want to try to use --fake-user if your service isn't running as root (And it's not a bad idea for backups even if you are running as root.) It seems like you may want an exclude line in the configuration to handle lost+found
    – roaima
    May 1 at 15:56

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.