Rsync Backup job NAS to USB drive suddenly displaying strange behaviour

[bedlam1]

The backup job in question has been running flawlessly 3 times a day for the last year.(alongside a similar job which is not mis-behaving)

The only change I have made since this began is installing OS 6.7.4

The settings are:

The Source Type is "volume" and the Name is "volume: data" Everything else is blank.

The Destination is Type "remote" and the Name is "remote: RSync Server", Host is "localhost" and Path is "USB_HDD_1/NAS_IAN_Backup"

Under Advanced compression is disabled and Remove deleted files on target is checked.

The USB Drive is NTFS format.

The odd behaviour is as follows:

The log shows the log as starting and completing within one second !!! and reports Backup Status: Success

Which is clearly not correct.

The log also shows the following:

sending incremental file list

sent 733 bytes received 41 bytes 1,548.00 bytes/sec
total size is 2,930 speedup is 3.79
S): Operation not supported (95)
rsync: set_acl: sys_acl_set_file(data/Documents, ACL_TYPE_ACCESS): Operation not supported (95)
rsync: set_acl: sys_acl_set_file(data/Downloads, ACL_TYPE_ACCESS): Operation not supported (95)
rsync: set_acl: sys_acl_set_file(data/Ians_Stuff, ACL_TYPE_ACCESS): Operation not supported (95)
rsync: set_acl: sys_acl_set_file(data/Music, ACL_TYPE_ACCESS): Operation not supported (95)
rsync: set_acl: sys_acl_set_file(data/PC_Backup, ACL_TYPE_ACCESS): Operation not supported (95)
rsync: set_acl: sys_acl_set_file(data/Pictures, ACL_TYPE_ACCESS): Operation not supported (95)
rsync: set_acl: sys_acl_set_file(data/Recovered_Data, ACL_TYPE_ACCESS): Operation not supported (95)
rsync: set_acl: sys_acl_set_file(data/Transmission, ACL_TYPE_ACCESS): Operation not supported (95)
rsync: set_acl: sys_acl_set_file(data/Videos, ACL_TYPE_ACCESS): Operation not supported (95)
rsync: set_acl: sys_acl_set_file(data/couchpotato, ACL_TYPE_ACCESS): Operation not supported (95)
rsync: set_acl: sys_acl_set_file(data/sickrage, ACL_TYPE_ACCESS): Operation not supported (95)
data/Documents/
data/Downloads/
data/Ians_Stuff/
data/Music/
data/PC_Backup/
data/Pictures/
data/Recovered_Data/
data/Transmission/
data/Videos/
data/couchpotato/
data/sickrage/

sent 838 bytes received 1,308 bytes 4,292.00 bytes/sec
total size is 2,930 speedup is 1.37
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.1]

I am totally stumped by this and am hoping someone here can help me or better still provide a solution

[StephenB · Accepted solution]

Did you check the permissions and owners for these particular MP3s?  Right-click in file explorer, etc...

[crazy_toy]

Hi badiam1

I dont understand job's setting , destination is 'remote' , host should be remote server host , not localhost

Could you please paste settings' screenshot?

Thanks

[StephenB]

---

@crazy_toy wrote:

I dont understand job's setting , destination is 'remote' , host should be remote server host , not localhost

---

He's backing up to a locally connected USB drive using rsync, so the "remote" destination has to use localhost.

It'd be far more direct if you could specify rsync with local source and local destination, but you can't do that.

[bedlam1]

That's exactly correct @StephenB

Shame Netgear "experts" don't know that

Am still hoping for someone more knowledgeable to help withe the ACL problem

[jak0lantash]

Does the issue in that thread look similar to what you're experiencing?

https://community.netgear.com/t5/Using-your-ReadyNAS/Rsync-broken-since-6-7-1-amp-6-7-3/m-p/1294160#...

[bedlam1]

There are some similarities @jak0lantash, but OS 6.7.4 triggered my problem and as shown above there are ACL errors.

I have sent a PM to @mdgm-ntgr referencing both posts and seeking help

[bedlam1]

I decided to revert back to OS 6.7.1 and my backup job is working as normal.

I will leave the thread open for now as there is clearly a problem with OS 6.7.4 

[JennC]

Hello bedlam1,

Firmware version 6.7.5 has been officially released today, in case you are interested.

Regards,

[jak0lantash]

---

@bedlam1 wrote:

I decided to revert back to OS 6.7.1 and my backup job is working as normal.

---

I hope this won't cause any issue moving forward. Downgrading isn't "supported", so it's not tested.

[bedlam1]

Tthank you @JennC

@jak0lantash I have been keeping tabs on developments of 6.7.4 and installing them along the way, culminating in 6.7.5 today.

2017/06/01 16:22:45 UTC] Updated from ReadyNASOS 6.7.4 (ReadyNASOS) to 6.7.1 (ReadyNASOS).
[2017/06/09 17:11:33 UTC] Updated from ReadyNASOS 6.7.1 (ReadyNASOS) to 6.7.5-T299 (Beta 1).
[2017/06/16 07:50:42 UTC] Updated from ReadyNASOS 6.7.5-T299 (Beta 1) to 6.7.5 (RC1).
[2017/06/21 19:44:46 UTC] Updated from ReadyNASOS 6.7.5 (RC1) to 6.7.5 (ReadyNASOS).

My backup has been working

There have been no signs of any issues apart from one

The backup log includes "errors" like these

rsync: set_acl: sys_acl_set_file(data/Music/Iguana Music/No 01 at 29-06-2013/334 - The Man Behind C. - Yellow Fall (Jazzfinger Mix).mp3, ACL_TYPE_ACCESS): Operation not supported (95)

The error is restyricted to only.mp3 files, and then not all of them

The last line of the log includes this

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

[StephenB]

I suspect that if you look at these particular files you'll find that the backup doesn't have the same owner and/or file permissions as the source.

[bedlam1]

I made changes to permissions/access in an effort to spark something, it initiated a resync,having now run the backup again I am still getting the same errors.

However, I have also run ViceVersa Pro to compare the data version and the backup data version which confirms they are an exact replica

So I can only conclude the errors showing up are false

[StephenB]

---

@bedlam1 wrote:

So I can only conclude the errors showing up are false

---

Well, the error didn't say that the rsync copy failed.  It said that rsync couldn't set the permissions to match the source.

So I think the errors are likely real, but comparing the files would still show them to be identical.

You could try resetting the permissions on the share that holds the MP3s. 

[bedlam1]

Did that this morning.....caused a resync, but no change to the backup job results log

[StephenB · Accepted solution]

Did you check the permissions and owners for these particular MP3s?  Right-click in file explorer, etc...

[bedlam1]

Thanks for the interest @StephenB

Changed the owner of the whole Music share to Admin (it was Guest) and File Access to Users (it was guest), deleted the backup "Music" and ran the backup job again, no change. I think I will just live it until I have time to check the Windows Permissions/Ownership fully, particularly as I have a very simple Home setup of which I am the only user.

[bedlam1]

Spent some time on Permissions in Windows Explorer today and made some changes.

Deleted the whole Music Backup dataset, ran my Rsync Backup job, on viewing the log there are now no "errors" shown.

Not sure which change I made resolved the issue but many thanks to @StephenB for the pointer

[StephenB]

Glad you got it fixed.

[bedlam1]

I spoke too soon, random ALC messages are back in the Backup log, the job completes, the Backup data is a complete mirror of the data.

Clearly something is not right either in Rsync or Win 10.

Am just going to ignore it 

[StephenB]

---

@bedlam1 wrote:

Clearly something is not right either in Rsync or Win 10.

---

I think it's a mismatch between NTFS file permissions and standards linux file permissions.

It should be safe to ignore.

[Sharpy]

How did you solve this problem I'm having the same problem 

And my backup sizes Dont match the source sizes so I'm assuming that these files didn't copy