Exception 'Ace type 9 is not supported yet'

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Exception 'Ace type 9 is not supported yet'

Mr P Upfold
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 [hidden email]
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Exception 'Ace type 9 is not supported yet'

Dominic Raferd-3
On Thu, 9 May 2019 at 08:49, Mr P Upfold <[hidden email]>
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
_______________________________________________
rdiff-backup-users mailing list at [hidden email]
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki