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,
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.