All,
We have been using rdiff-backup successfully for several years to perform an
offsite backup. The source machine in this case is Windows Server 2012 R2
(using an admittedly older distribution of cwRsync, although rdiff-backup.exe
itself is v1.2.8). The destination is rdiff-backup v1.2.8 on FreeBSD
11.2-RELEASE-p9 using SSH as the transport.
Since 01/05/2019, backups have not been succeeding. I even started a brand new
data set to eliminate the possibility of some corruption of the incremental
data, but the failure is as follows:
Exception 'Ace type 9 is not supported yet' raised of class '<type
'exceptions.NotImplementedError'>':
File "rdiff_backup\robust.pyc", line 32, in check_common_error
File "rdiff_backup\rpath.pyc", line 1149, in append
File "rdiff_backup\rpath.pyc", line 884, in __init__
File "rdiff_backup\rpath.pyc", line 909, in setdata
File "rdiff_backup\rpath.pyc", line 1499, in setdata_local
File "rdiff_backup\win_acls.pyc", line 228, in rpath_acl_win_get
File "rdiff_backup\win_acls.pyc", line 60, in load_from_rp
Sending back exception Ace type 9 is not supported yet of type <type
'exceptions.NotImplementedError'>:
File "rdiff_backup\connection.pyc", line 335, in answer_request
File "rdiff_backup\connection.pyc", line 485, in readfromid
File "rdiff_backup\iterfile.pyc", line 302, in read
File "rdiff_backup\iterfile.pyc", line 325, in addtobuffer
File "rdiff_backup\rorpiter.pyc", line 342, in next
File "rdiff_backup\selection.pyc", line 132, in Iterate_fast
File "rdiff_backup\selection.pyc", line 120, in diryield
File "rdiff_backup\robust.pyc", line 32, in check_common_error
File "rdiff_backup\rpath.pyc", line 1149, in append
File "rdiff_backup\rpath.pyc", line 884, in __init__
File "rdiff_backup\rpath.pyc", line 909, in setdata
File "rdiff_backup\rpath.pyc", line 1499, in setdata_local
File "rdiff_backup\win_acls.pyc", line 228, in rpath_acl_win_get
File "rdiff_backup\win_acls.pyc", line 60, in load_from_rp
On a couple of occasions, the file logged immediately before this error is in
the AppData/Roaming folder of a Windows user's profile. It has been different
files, but in both cases, Windows shortcut files.
Processing changed file
[redacted]/AppData/Roaming/Microsoft/Windows/Recent/[redacted].jpg.lnk
My reading of "Ace type 9" suggests it might be as follows (from my research,
all I could immediately find online was a possible match in the unrelated
ntfs-3g source code)
ACCESS_ALLOWED_CALLBACK_ACE_TYPE = 9,
The Microsoft documentation I can find for this reads:
When the AuthzAccessCheck function is called, each
ACCESS_ALLOWED_CALLBACK_ACE structure contained in the DACL of a
SECURITY_DESCRIPTOR structure passed through a pointer to the AuthzAccessCheck
function invokes a call to the application-defined AuthzAccessCheckCallback
function, in which a pointer to the ACCESS_ALLOWED_CALLBACK_ACE structure found
is passed in the pAce parameter.
Running icacls on the file doesn't suggest any special access control entry is
on this file -- it inherits from its parent folders which back up successfully
and doesn't have any of its own ACEs as far as I can see.
I'm at a loss as for why this issue is newly affecting us on a source data set
that has worked well for years. I'm going to exclude certain folders in
AppData/Roaming that I think contain shortcut files for now and try again, but
it takes some time to create a new backup set, so I won't know if this
workaround helps immediately.
Would anyone be able to shed light on this issue? Is there a way to make a
failure to copy (this kind of) ACE non-fatal?
Peter Upfold
IT Technician
Test Valley School
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
