Duplicacy Web Edition restore fails with "permission denied" error

Bug
#1

Please describe what you are doing to trigger the bug:
Using the Web UI to restore a single file from a backup to the Desktop.

Duplicacy 2.6.2
Duplicacy Web Edition 1.4.1
macOs Mojave 10.14.6 (18G6020)

Please describe what you expect to happen (but doesn’t):
File should be restored on Desktop. I am able to restore to /tmp successfully.

Please describe what actually happens (the wrong behaviour):

2020-09-29 11:10:15.377 INFO REPOSITORY_SET Repository set to /Users/ben/Desktop
2020-09-29 11:10:15.378 INFO STORAGE_SET Storage set to b2://duplicacy-work-backup
2020-09-29 11:10:16.764 INFO BACKBLAZE_URL download URL is: https://f002.backblazeb2.com
2020-09-29 11:10:17.566 INFO SNAPSHOT_FILTER Loaded 1 include/exclude pattern(s)
2020-09-29 11:10:18.964 INFO RESTORE_INPLACE Forcing in-place mode with a non-default preference path
2020-09-29 11:10:18.964 ERROR RESTORE_MKDIR Failed to create the preference directory: mkdir /Users/ben/Desktop/.duplicacy: permission denied

#2

Does Duplicacy have permissions to write to your desktop, including FullDiskAccess privilege?

#3

I don’t know, how can I check? I installed web edition with the default settings and it didn’t have any prompts about FullDiskAccess. If this is a requirement to access certain directories, perhaps there should be some guidance in the UI about how to change this permission?

1 Like
#4

You can search this forum for “full disk access”. It’s a macos feature that protects “sensitive” directories and is described here: Change Privacy preferences on Mac - Apple Support

I agree though that Duplicacy Web application must prompt the user to grant it full disk access permission if access to those areas are requested by the user. Daisy disk would be an example of the user experience requesting that.

1 Like
#5

I gave the web application full disk access and was able to restore successful to the same Desktop folder which previously failed due to lack of permissions.

In order to improve the user experience, I would suggest (1) the web app asks for full disk access permissions during installation (2) the restore function in the web app checks that the restore destination is writable before proceeding

2 Likes
#6

Same issue using web-duplicacy 1.6.2 under Synology docker. Why is this is still an issue two years later?

#7

Synology does not have SIP, it can’t be the same issue.

On Synology make sure duplicacy user is a super user or set the flag to ignore owner.

#8

Figured it out. Docker container settings had the shares set to read-only. As I recall, the initial setup I followed for the docker install set the shares to read-only as a safety feature… changing it allowed it to restore successfully.