rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[rdiff-backup-users] Exception 'Ace type 9 is not supported yet'


From: Mr P Upfold
Subject: [rdiff-backup-users] Exception 'Ace type 9 is not supported yet'
Date: Thu, 9 May 2019 07:48:49 +0000

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]