mounting backup makes mount point 'disapear'... #490
Labels
No Label
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: borgmatic-collective/borgmatic#490
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What I'm trying to do and why
Mount back up to browse
Steps to reproduce (if a bug)
Actual behavior (if a bug)
See above, mount point 'disapears' - or at least can not be accessed on mounting
Expected behavior (if a bug)
Mount of archive is accessable
Other notes / implementation ideas
The archive is on xfs and the mount on ext4:
Environment
borgmatic version: 1.5.21
Used
sudo borgmatic --versionborgmatic installation method:
sudo dnf install borgmaticFrom here:
https://copr.fedorainfracloud.org/coprs/heffer/borgmatic/repo/epel-8/heffer-borgmatic-epel-8.repo
Borg version: borg 1.1.17
Used
sudo borg --versionPython version: Python 3.6.8
Used
python3 --versionDatabase version (if applicable): n/a
Use
psql --versionormysql --versionon client and server.operating system and version: Linux frontserver.lan 4.18.0-348.7.1.el8_5.x86_64 #1 SMP Tue Dec 21 19:02:23 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
This works:
I believe this is just how mounting in Linux works—you're mounting with sudo in this case, which means the path is mounted with root's permissions.. And that includes the mount point itself, which effectively gets "masked" by whatever's mounted there until it's subsequently unmounted.
So, options for dealing with this:
borgmatic mount --optionsthat allow non-root users to browse. One option I can think of trying would be--options uid=value. Check out the documentation formountthough for more options./etc/fstab) with appropriate options.Thanks @witten, but I'm not sure about that - both
/mnt/RAID1-699GiBand/mnt/tmp2are owned by root but readable.Gives default directory permissions of 755, or o=rwx g=r-x a=r-x - which is as for
/mnt/RAID1-699GiBand/mnt/tmp2.But, I'm not sure I've added much there other than pointing out that x=x & y=y...
Anyway, here it is as root:
Yeah, my understanding is that the permission of a mount point prior to mounting does not impact the permissions of the filesystem once mounted. Those permissions are taken from those in the mounted filesystem, in this case the Borg archive. I think one of the options listed above is probably your best bet. I'd first try accessing the mounted path as the root user and make sure at least that works.
Oh, I just saw that
/mnt/tmp1: Mountpoint must be a writable directory! Not sure what's going on there if you're getting that as root. My guess would be thattmp1is already somehow mounted? Have you tried unmounting it?umount /mnt/tmp1as root.Having a similar problem on Fedora (which it appears you're also running). Not sure if I should post here or start a new issue. Seems more like the the file manager (Nautilus) is at fault here. Wondering if and how you ever got it resolved?
When mounting a backup with sudo borgmatic mount --archive latest --mount-point /mnt/borgbackuplatest the directory/folder (/mnt/borgbackuplatest) would no longer be browsable using the default file manager in Fedora. Instead I would get the popup error message "This location could not be displayed" with the underlying message being "you do not have the permissions necessary to view the contents of "borgbackuplatest". When unmounted the mount directory would be browsable but predictably empty.
Running Nautilus (default file manager on Fedora) with root privileges from the terminal (sudo nautilus) allows me to see the contents of my mounted backup but how come I cannot open the mounted directory as root from my default instance of Nautilus. In other words without openining up a privileged instance of the file manager. I can open other root protected directories as root from the default instance of the file manager such as the root folder and lost&found. With those folders navigating to them through the file manager a popup prompt would ask me for my password and allow me in.
Update: Not sure if I'm allowed to provide links here but this seems more like a issue (good security practice by design) related to the Nautilus file manager, issue report & discussion here.
https://gitlab.gnome.org/GNOME/nautilus/-/issues/1282
Actually, Rocky
Not solved; I do not think this bug is related to Nautilus - I'm not using Nautilus with borgmatic.
I'm running borgmatic on a small headless home server.
Slightly OT this thread, but the link you've given to Nautilus issue can be solved by the installation of the nautilus-admin extension:
https://www.how2shout.com/linux/open-ubuntu-file-manager-as-root-user/
But, the project seems dead:
https://github.com/brunonova/nautilus-admin
Also, the instructions to use the
admin:///uri works.If you're using borg with gnome I strongley suggest installing Pika Backup:
https://gitlab.gnome.org/World/pika-backup
It's a young project but moving very fast. Very slick, simple and straight forward user backup gui to borg. It's very soon to release v0.4 which will intruduce scheduled b/u. Until then, I've just had it set as a start up app so whenever I log in I get prompted to do a backup.
I think you would do better starting a new bug, because this has veered rather OT.
So @psued, did it turn that out that
tmp1was somehow already mounted?Thanks @witten. No, the only sense in which
tmp1was/is mounted is that it is mounted by the root filesystem on/dev/mapper/cl_frontserver-rootat/mnt/tmp1as per/etc/fstab(other than when this bug is evident as per the OP)But also:
So, it's just not being root when attempting to browse - which you mentioned and is a bit bleeding obvious... but, I guess got lost in the noise. Sorry about that. Closing.
But, still - isn't a bit weird that
/mnt/tmp1has the same permissions as the other directories in/mnt- of which/mnt/RAID1-699GiBpermanently (ie, via/etc/fstabon boot) has an external file system mounted on it and/mnt/tmp2has never (for our purposes) has another file system mounted on it, and they can be read and traversed?Ah, I think it's begining to dawn on me what you've been saying -
borgcreates and mounts the backed-up directory at some point in time as a directory with the user permissions of the user creating the backup files -borgdoesn'tmountan existingdirectory(with its permissions) as such, but creates adirectoryfrom the backupfilesand gives thatdirectorythe permissions of the user making that backup.That's correct! At least, that's my understanding of how it works.
Happiness :)