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

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

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


From: Dominic Raferd
Subject: Re: [rdiff-backup-users] Exception 'Ace type 9 is not supported yet'
Date: Thu, 9 May 2019 09:40:28 +0100

On Thu, 9 May 2019 at 08:49, Mr P Upfold <address@hidden>
wrote:

> 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?
>

I advise running rdiff-backup from Windows with --no-acls, and following
any restore consider using icacls to fix permissions back to the standard
inherited ones e.g.
icacls %APPDATA%\Thunderbird /reset /t /c /q

Dominic Raferd
https://www.timedicer.co.uk


reply via email to

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