TW
@Nikratio needs to decide, I can fix it afterwards.
## status quo borg 1.x borg does not deal with "users", only with repositories. also, there are no management commands/features for more than the "single repository" scope. by default, it...
## borg 2.x? borg2 might use borgstore and there is the related ticket about disk space / quota / etc.: https://github.com/borgbackup/borgstore/issues/19
see #8824, closing as "not planned".
iirc we already have some issue about this on this issue tracker.
#8837 implemented `BORG_REPO_PERMISSIONS=read-only` env var - most of the repo will be r/o then, except the `locks/` directory. It also implements `BORG_REPO_PERMISSIONS=no-delete` - with that, destructive operations (like delete and...
Only allowing archives to get deleted (and NOT allowing archives to get listed or extracted) currently can't be done with BORG_REPO_PERMISSIONS, because all these chunks are stored together below `data/`:...
That tarsnap approach with different cryptographic keys is quite different from the simple permissions check from my previous post - interesting!
Yes, guess that is a setup that should work. The permissions are enforced at the `borgstore` api level. If e.g. deleting an object is tried, but not allowed, it will...
Try to reproduce the issue with a local repository, to determine whether there is a general problem with borg or just with borg client/server (and thus: likely the network connection...