Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use different permissions when mounting archive. #520

Closed
geckolinux opened this issue Jun 19, 2020 · 3 comments · Fixed by #682
Closed

Use different permissions when mounting archive. #520

geckolinux opened this issue Jun 19, 2020 · 3 comments · Fixed by #682
Labels
type:bug Something doesn't work as intended

Comments

@geckolinux
Copy link

geckolinux commented Jun 19, 2020

Hi, I'm running Vorta 0.6.26 and Borg 1.1.13 on openSUSE Tumbleweed.

I just discovered a really weird anomaly with Vorta. I tested a backup of my Firefox ~/.mozilla directory by using Vorta to mount the repo to ~/Desktop/a, renaming my ~/.mozilla folder and using Dolphin to copy it from ~/Desktop/a/home/myself/.mozilla to its normal location. This consistently led to a corrupt Firefox profile, as described here. I don't understand all the moving parts in Firefox, but it's either a permissions problem or some other kind of corruption with one of the sqlite databases it uses.

By simply creating a filesystem copy of the ~/.mozilla profile on my local disk and closing Firefox and renaming the original profile and copying back the backup, Firefox launches as expected as if nothing happened.

So I tested again with the same process as described above, except I manually created the backup and manually mounted it with borg create and borg mount, and repeated the profile restore process. This also worked as expected.

Then I manually mounted with borg mount a backup created with Vorta and restored my profile from that, which also worked correctly.

Then I used Vorta to mount the manually created borg backup described above, and this gave me a corrupted profile.

So Vorta must be doing something weird with the way it's mounting the backups. I confirmed this happens every time I tried to mount it via Vorta and restore the profile, both from a USB HD repo and from my NAS over SSH.

Thanks for the help.

@ghost
Copy link

ghost commented Jun 19, 2020

I believe this is caused by permissions, specifically the "-o umask=0277,uid=1000" portion of the mount command vorta uses. I ran the mount command with the options, and all the files became read only. I then ran the command without the options, and all the files kept their permissions.

Update: I narrowed it down to the umask=0277 portion, running mount as
borg --log-json mount -o uid=1000 SOURCE DESTINATION
from command line seems to preserve permissions.

@ghost
Copy link

ghost commented Jun 19, 2020

Fixing this conflicts with the intent of #362, but for a full profile restore, it is better to use borg extract. Going to make a checkbox to toggle this behaviour on and off, to have the best of both worlds.

@geckolinux
Copy link
Author

Going to make a checkbox to toggle this behaviour on and off, to have the best of both worlds.

That would be awesome, thanks very much for considering different needs!

@samuel-w samuel-w added the type:bug Something doesn't work as intended label Sep 4, 2020
@m3nu m3nu changed the title Restore from Vorta mounted repo corrupt, proper with borg mount command Use different permissions when mounting archive. Feb 15, 2021
@m3nu m3nu closed this as completed Feb 15, 2021
@borgbase borgbase locked and limited conversation to collaborators Feb 15, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
type:bug Something doesn't work as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants