Share backup with 2 users

[Jopp-gh]

I want to share my Borg backup with two users, let's call them user A and user B. Both user accounts are local accounts.

Adding both users and the mounting point to the Same group, eg "borg" isn't enough.
How should I setup my backup drive, to allow user B to mount the backup from user A ?

[jmrplens]

A common group and a shared directory are not enough because Borg writes with umask 0077 by default, so everything in the repository ends up owned by user A with mode 0600 and the group bit is useless. You need --umask 002 on every Borg call from both users, and there is a trap if one of them forgets.

I set this up with two local accounts, both in a borg group, and a setgid directory (chgrp borg /srv/backup && chmod 2775 /srv/backup), which is the setup you describe. With the default umask, user B cannot even list the repository, and the error does not mention reading at all:

Failed to create/acquire the lock /srv/backup/repo/lock.exclusive
([Errno 13] Permission denied: '/srv/backup/repo/lock.exclusive.<...>.tmp')

With --umask 002 the repository is created as drwxrwsr-x with -rw-rw-r-- files, B lists it, and borg create --umask 002 from B adds an archive to A's repository without complaint.

The trap: that flag has to be on every call from both users. I ran one borg create from B without it, and the files it wrote (nonce, index.N, hints.N, integrity.N) landed as -rw------- owned by B, so A's next run died with KeyError: 13 and AssertionError: cleanup happened in Repository.__del__. It is recoverable with chmod -R g+rwX on the repository, but it will happen again unless both sides always pass the flag.

In Vorta, put --umask 002 in the Extra borg arguments field of the repository, in both users' profiles. Vorta inserts those arguments right after the subcommand (src/vorta/borg/borg_job.py, cmd = cmd[:2] + extra_args + cmd[2:]), which is where Borg accepts its common options, so it applies to every command Vorta runs against that repository, not just to backups.

For the mounting part there are two separate things. A FUSE mount is private to the user who made it: B can mount A's repository and browse it, but A gets Permission denied on B's mountpoint even when the directory permissions would allow it. If you want the other user to see it, you need user_allow_other in /etc/fuse.conf and -o allow_other on the mount. And check Vorta's security setting "Try to replace file permissions when mounting an archive": when it is on, Vorta mounts with -o umask=0277,uid=<the user mounting> (src/vorta/borg/mount.py), which makes the mount unreadable to anyone else, so turn it off for this scenario.

Two things worth weighing before you go down this path. Each user keeps their own chunk cache in ~/.cache/borg, so every time the other one has touched the repository, the next backup starts with a full resync: in my test A's second backup printed Synchronizing chunks cache... Archives: 2, w/ cached Idx: 0, w/o cached Idx: 2 and rebuilt the index from every archive, which on a real repository is slow. And Borg's own FAQ says that pointing several clients at one repository is "possible from the technical standpoint, but it is not recommended from the security perspective", because its attack model assumes a single client.

So the umask route works, as measured above, but it stays correct only while every invocation from both sides remembers the flag, and it costs a cache resync on every handover. If what you actually want is for both accounts to back up to the same disk, two separate repositories under the same shared directory avoid all of this, and still deduplicate within each user's own data.

[Jopp-gh]

Amazing research! I wouldn't have gotten so far. Taking note, so your results aren't wasted and my questions covered in case I stumble again over similar questions.

Yes, backups shouldn't be shared, there's nothing to add. I've been in this situation more than once where I had to share local backups. The common (and sound) protocol is to backup for one user only, no matter what backup solutions and OS I used.

Well, at this point the best will be to create some ISO, from necessary data, not the whole home DIR. Thanks again for your kind help and easy to follow research!