QNAP files restored to a new location are inaccessible, CLI 2.7.2

Please describe what you are doing to trigger the bug:

Using QNAP qpkg for x86 w/ CLI version 2.7.2.
Restore directory to new location:

2020-11-17 12:59:27.039 INFO REPOSITORY_SET Repository set to /share/homes/Keith/Downloads/Restored
2020-11-17 12:59:27.039 INFO STORAGE_SET Storage set to /share/TR-004/Duplicacy/storage
2020-11-17 12:59:27.039 INFO SNAPSHOT_FILTER Loaded 1 include/exclude pattern(s)
2020-11-17 12:59:27.041 INFO RESTORE_INPLACE Forcing in-place mode with a non-default preference path
2020-11-17 12:59:30.306 INFO SNAPSHOT_FILTER Parsing filter file /share/CACHEDEV1_DATA/.qpkg/Duplicacy/.duplicacy-web/repositories/localhost/restore/.duplicacy/filters
2020-11-17 12:59:30.306 INFO SNAPSHOT_FILTER Loaded 0 include/exclude pattern(s)
2020-11-17 12:59:30.306 INFO RESTORE_START Restoring /share/homes/Keith/Downloads/Restored to revision 36
2020-11-17 12:59:30.632 INFO DOWNLOAD_PROGRESS Downloaded chunk 1 size 11270829, 10.75MB/s 00:00:01 100.0%
2020-11-17 12:59:30.660 INFO DOWNLOAD_DONE Downloaded Household Documents/Music/music appreciation class 2020/Mid Baroque composers fugue.docx (19034)
2020-11-17 12:59:30.660 INFO DOWNLOAD_DONE Downloaded Household Documents/Music/music appreciation class 2020/OLAD baroque elements.docx (22104)
2020-11-17 12:59:30.660 INFO RESTORE_END Restored /share/homes/Keith/Downloads/Restored to revision 36
2020-11-17 12:59:30.660 INFO RESTORE_STATS Files: 2 total, 40K bytes
2020-11-17 12:59:30.660 INFO RESTORE_STATS Downloaded 2 file, 40K bytes, 1 chunks
2020-11-17 12:59:30.660 INFO RESTORE_STATS Skipped 0 file, 0 bytes
2020-11-17 12:59:30.660 INFO RESTORE_STATS Total running time: 00:00:03

See https://forum.duplicacy.com/t/qnap-files-restored-to-a-new-location-are-inaccessible/4350/3?u=gorlen

Please describe what you expect to happen (but doesn’t):

Restored parent directories should have same permissions as backed-up directories.

Please describe what actually happens (the wrong behaviour):

Permissions of parent directories are incorrect, making restored files inaccessible:

Did you pass the -ignore-owner option to the restore command? Without this option Duplicacy should update the owner and group of each restored directory.

The problem occurs both with and without the -ignore-owner option.

Is a fix for this planned?

The Web UI doesn’t default the “Restore to” field to the preference path, so an incorrect path is prone to be entered (https://forum.duplicacy.com/t/restore-location-protection-default/4441/4?u=gorlen), then when files are restored to a non-default preference path, they are invisible to Windows clients because of this bug, causing confusion.

1 Like

Any progress on fixing this bug?

Did you test it with CLI 2.7.2?

I mentioned in this post that the ACL fix may have fixed this issue too.

I just retested with CLI 2.7.2. There are two problems when restoring a folder to a new location:

  1. Permissions are still not set correctly on the parent directories of the restored folder.
  2. Permissions are not correct for the files/folders restored from old snapshots, presumably because these were backed up before the ACL fix. The following shows the differences between restoring an old snapshot and the most recent, both with -ignore-owner (RESTORE_INPLACE Forcing in-place mode with a non-default preference path):

I’ll look into this bug.

Did you mean files/folders backed up after the ACL fix are restored correctly?

Better still, why even create these folders?


On further thought, why should this be? If the CLI pre-2.7.2 did not back up ACLs correctly in old shapshots, and the files haven’t been modified since CLI 2.7.2 was released in Nov 2020, what would trigger the ACLs to be backed up again?

Restore always preserves the folder structure. The destination folder is treated as another repository, the same way as the source directory.

All extended attributes are read when indexing files regardless of whether they have been modified or not.