Restores failing due to failure to change UID or GID

Support
#1

I have my backups working using the Duplicacy Web Edition and tested now to be sure I can recover files. I tried to recover a file and received this error message:

The restore command encountered an error:
Failed to change uid or gid: lchown /media/16tbexpansion/temprecovery/US/PersonalCarney/RealEstate/3_Windmill_Road/Gardening/2023_Catalog_CumberlandValleyNursery_CCE_000141.pdf: operation not permitted

Exit code: 100

I have created the folder /media/16tbexpansion/temprecovery as follows:

drwxrwxr-x 4 duplicacy duplicacy 4096 Mar 23 08:58 temprecovery/

Inside that folder is another folder just created by Duplicacy Restore for which I set up the following permissions:

drwxrwxr-x 2 duplicacy duplicacy 4096 Mar 23 08:58 .duplicacy/

I had figured that folder would have enough permissions for Duplicacy to write to. But, I am wondering what I might have to do in order for the software to be able to change the UID and GID.

But, on second thought… I just discovered that the restore is able to create the sub directories and recover A FILE. But… as soon as it tries to change the permission on the first file, then the recovery fails. I just tried to recover a folder with multiple files and ONLY the first file is there:

/media/16tbexpansion/temprecovery/US/PersonalCarney/RealEstate/3_Windmill_Road/Gardening/Grafting/

-rwxrwxr-x 1 duplicacy duplicacy 77827 Mar 23 13:53 ‘# Handling of Scion wood 2016.pdf’*

Do I need to maybe put the duplicity user into some other groups? I wish there was a way for the user and group of the file to be retained when the file is uploaded to Wasabi as well as when it is downloaded during a recovery.

I did read another ticket where somebody suggested to somehow ignore-owner.

If that is the answer, how can I do that within the Web Edition?

Somebody else suggested running Duplicacy Web Edition as root. Is that a reasonable option? If so, how would I do that in the Web Edition?

BTW, here is the contents of my duplicacy-web.service file:

[Unit]
Description=Duplicacy Backups

[Service]
User=duplicacy
Group=duplicacy
Environment="HOME=/home/duplicacy"
WorkingDirectory=/home/duplicacy
ExecStart=/home/duplicacy/bin/duplicacy_web
Restart=on-failure
RestartSec=30

[Install]
WantedBy=multi-user.target

Thanks, Sean Carney

#2

You can enter -ignore-owner to the Options input box on the Restore page.

1 Like
#3

That was definitely the solution I was needing. Thank you.

#4

-ignore-owner works, but I’d prefer having a way to backup and restore as root without having the entire web interface running as root.

#5

Run duplicacy on Synology directly, as root, without their apps and/or containers.

#6

That’s what I have already been doing (running native without using docker) by following your guide precisely :).

Per your suggestion, I created a separate user duplicacy for running duplicacy_web as a systemd service (previously upstart). I suppose whenever I need to restore, I could manually switch it to root?

#7

Yeah, that is one way. Another way is to force duplicacy CLI to always run as root – regardless of who launched it, including web UI running as regular user – with setuid. Here is a demo:

We can’t use shell for this, because it messes with setuid, so here is a C program.

$ cat test.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main() {
    if (execl("/usr/bin/whoami", "whoami", NULL) == -1) {
        perror("execl");
        return 1;
    }
    return 0;
}

This short snippet will launch whoami. Build it and mess with flags:

 $ cc test.c -o meow
 $ ./meow
alex
 $ sudo chown root:root meow
 $ sudo chmod +s meow
 $ whoami
alex
 $ ./meow
root

I’m not sure if web UI needs to read any files created by duplicacy CLI – because in this case it won’t be able to. But worth a shot :slight_smile: