PBS backups owned by wrong user after restoring

[dmpm]

I messed up my PVE that PBS was running under, so I created datastores on my USB drive and synced the original datastores to that before reinstalling PVE, and then restoring PBS from a local snapshot backup.

I couldn't work out how to sync back from the USB datastores to the original location, so I just did a cp -RP job which should have preserved the ownership details, but the files on the USB were owned by backup:backup and after copying them back to the original location they were owned by root:root. So I did a chown -R backup:backup on them, but when i went to run the backup jobs to update the backups it was failing on the grounds that they were owned by root@pam rather than the user set in my backup jobs - pbsbackup@pbs ,

I fixed it by deleting most of the existing backups and running the job to create new ones, but for future reference, was there anything else I could have done to change the ownership backup to pbsbackup@pbs?

 

[Chris]

Hi,
you have to distinguish between ownership and permissions on the filesystem and the ownership of backup groups as managed by PBS. The latter one can be changed via CLI or WebUI. See also https://pbs.proxmox.com/docs/backup-client.html#changing-the-owner-of-a-backup-group

 

[dmpm]

Hi,
thanks, I found the option in the GUI to change the owner by right-clicking on each backup.

I tried via the CLI as well as that would be quicker when I've got a lot of backups to change. It doesn't seem possible from the PBS shell as proxmox-backup-client isn't installed there, so I tried it from my PVE machine using:

proxmox-backup-client change-owner ct/101 pbsbackup@pbs --repository 10.10.18.202BS-DM-USB

and that asked me for the password for root@pam and then showed the fingerprint and asked me if I was sure I wanted to continue connecting (it did this twice) and then it said "storing login ticket failed: $XDG_RUNTIME_DIR must be set". If I retry it doesn't show the fingerprint and just asks for the password for root@pam and then shows that error.

 

[Chris]

and that asked me for the password for root@pam and then showed the fingerprint and asked me if I was sure I wanted to continue connecting (it did this twice) and then it said "storing login ticket failed: $XDG_RUNTIME_DIR must be set". If I retry it doesn't show the fingerprint and just asks for the password for root@pam and then shows that error.

This error is however purely cosmetic: the client tries to store the login ticket in the location provided by the environment variable XDG_RUNTIME_DIR so you will not have to re-type the password for as long as the ticket is valid. Your shell environment does however seem to not set this, so no ticket is saved and you have to type the password again.

If you get no further output, the owner of the group has been changed.

 

[dmpm]

Thanks. I assumed that error meant it hadn't worked and didn't think to check, but I can see that it did.

I thought using the CLI might be quicker to change a lot of backups and it would have been a bit quicker if it had saved the password, but I would still have needed to edit the line each time to change the number of the ct or vm, so it ended up being quicker just to use the GUI.

It would be nice if we could select multiple files in the GUI and change them all at once, but I guess that's a limitation of using browser-based GUIs.