Freenas rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1053) [sender=3.0.9]

Question

Been at this for several days without luck.

After setting up an initial installation of Freenas complete with all users, groups and shares the USB failed. The data was all fine however, I did not have a backup of the configuration file. The version of Freenas used is FreeNAS-8.3.1-RELEASE-x64 (r13452)

After replacing the USB and setting everything up again - I reconnected the data hard disks and set about recreating all the users and groups again. All was fine until I got to setting up the Rsync backup script that I used for a local copy of the data onto an external USB hard disk.

The script I am using is

#!/bin/sh

# Simple script to backup data from BACKUP_SRC to BACKUP_DST
#
# this can be any drive attached to your FreeNAS box ...
# ... internal drive(s), external USB drive(s), external SATA drives(s)

# Backup source
BACKUP_SRC=/mnt/DATA/test/

# Backup destination -- DO NOT include the trailing slash
BACKUP_DST=/mnt/BACKUP1/SHARED

# For a seven day cyclical backup, remove the comment from the line 'DAY=option$
# set the preferred directory name format 'Monday, etc or Mon, etc'
# A = long day name   (i.e. Monday, Tuesday, ... Sunday)
# a = short day name  (i.e. Mon, Tue, ... Sun)
# This will create a daily backup directory (i.e. backup/Sat backup/Sun)
 DAY=/`date +%a`
#
 rsync -aqv -HAX --delete $BACKUP_SRC $BACKUP_DST$DAY

# In the event of a drive failure:
#
#   1. Replace failed hardware.
#   2. Recreate datasets and set appropriate permission
#   3. Reverse paths in this script and re-run it

# end

The script is executable with

chmod +x

However, the script fails with the following message

rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1053) [sender=3.0.9]

There are no log entries in /var/log/messages

Before recreating everything from scratch again - any pointers would be much appreciated

Thanks,

Answer 1

Apologies to both user2640725 and Joseph for the lack of feedback to your suggestions and to thank you for taking the time to respond to my question. I assumed I would be notified of answers to my question as a default - I have since changed this in my preferences

It seems that the problem was down to the "A" option in

rsync -aqv -HAX --delete $BACKUP_SRC $BACKUP_DST$DAY

According to Rsync Man pages

-A, --acls preserve ACLs (implies -p)

As soon as this was removed - the error went away. What is strange is that while testing this - I have the source and destination folders in the same file system - so I do not know what why this is causing a problem.

Will test a little more to see if there are some strange side effects to removing this option - but for the time being I prefer at least to have a copy of the data if at the expense of ACL attributes not being carried over.

Answer 2

I just run into this problem. The source directories had the s bit set on the group.

drwxrwsrwx 9 franz franz  4096 Okt 20  2015 Documentation/

This is the solution: Remove the group s bit on the folders and subfolders.

$ sudo chmod -R  g-s Classes/  Configuration/ Documentation/  Resources/

Now the rsync runs without errors:

rsync -av /var/www/html/typo3conf/ext/static_info_tables_it /run/media/franz/SICHER1/backup/typo3 

Answer 3

I happened got the same error code and figured out that the source directory is changed due to the hosting provider migrated their server. Verify if the path of $BACKUP_SRC do exist.

Answer 4

You can find more info without the -q parameter of rsync, and error code of rsync can be found here http://www.admon.org/faqs/how-to-understand-error-code-of-rsync/ or in rsync's manual page. Good luck!

Answer 5

I got this error while uploading assets of my webapp into azure, reason was that the old resources were being used and hence they could not be ovewritten. I had to stop server and then overwrite them.