How to mount a root backup and access it through a file manager as non-root #773

New Issue

hook · 2023-10-16T16:19:06Z

hook commented

2023-10-16 16:19:06 +00:00

What I'm trying to do and why

I run Borgmatic as a systemd unit as root, so I can pull /etc/ as well as /home/hook/.

I want to borg mount a backup and then be able to browse it with a file manager (e.g. Dolphin) so I can find what is missing and then copy-paste / drag’n’drop the files.

Steps to reproduce

Have Borgmatic run as a systemd “system” unit.

do:

try mounting as non-root:
1.1.borgmatic mount --mount-point /mnt/backup_mnt ↦ fail
mount as root:
1.2. sudo borgmatic mount --mount-point /mnt/backup_mnt
1.3. ls /mnt/backup_mnt ↦ fail

Actual behavior

Running borgmatic mount as non-root fails:

Can't determine which repository to use. Use --repository to disambiguate

summary:
Can't determine which repository to use. Use --repository to disambiguate

Need some help? https://torsion.org/borgmatic/#issues

Running sudo borgmatic mount works of course, but then the files are only accessible for root too.

ls /mnt/backup_mnt results in:

ls: /mnt/backup_mnt: Permission denied (os error 13).

Expected behavior

I just want a way to mount my backups and read them – at least the backups of my home – as my normal user.

Other notes / implementation ideas

Limitations I’ve noticed so far:

Borg(matic)/SSH, rightly, won’t let you weaken the ssh key permissions to have the /etc/borgmatic/ssh_key be readable by someone else
a (GUI) file manager, also rightly, won’t let you run it as root

borgmatic version

1.8.3

borgmatic installation method

EndeavourOS / Arch Linux package, using Yay

Borg version

borg 1.2.6

Python version

Python 3.11.5

Database version (if applicable)

No response

Operating system and version

NAME="EndeavourOS"
PRETTY_NAME="EndeavourOS"
ID="endeavouros"
ID_LIKE="arch"
BUILD_ID="2023.08.05"
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://endeavouros.com"
DOCUMENTATION_URL="https://discovery.endeavouros.com" 
SUPPORT_URL="https://forum.endeavouros.com"
BUG_REPORT_URL="https://forum.endeavouros.com/c/arch-based-related-questions/bug-reports" 
PRIVACY_POLICY_URL="https://endeavouros.com/privacy-policy-2"
LOGO="endeavouros"

### What I'm trying to do and why I run Borgmatic as a systemd unit as root, so I can pull `/etc/` as well as `/home/hook/`. I want to `borg mount` a backup and then be able to browse it with a file manager (e.g. Dolphin) so I can find what is missing and then copy-paste / drag’n’drop the files. ### Steps to reproduce Have Borgmatic run as a systemd “system” unit. do: 1. try mounting as non-root: 1.1.`borgmatic mount --mount-point /mnt/backup_mnt` ↦ fail 2. mount as root: 1.2. `sudo borgmatic mount --mount-point /mnt/backup_mnt` 1.3. `ls /mnt/backup_mnt` ↦ fail ### Actual behavior 1. Running `borgmatic mount` as non-root fails: ``` Can't determine which repository to use. Use --repository to disambiguate summary: Can't determine which repository to use. Use --repository to disambiguate Need some help? https://torsion.org/borgmatic/#issues ``` 2. Running `sudo borgmatic mount` works of course, but then the files are only accessible for root too. `ls /mnt/backup_mnt` results in: ``` ls: /mnt/backup_mnt: Permission denied (os error 13). ``` ### Expected behavior I just want a way to mount my backups and read them – at least the backups of my home – as my normal user. ### Other notes / implementation ideas Limitations I’ve noticed so far: - Borg(matic)/SSH, rightly, won’t let you weaken the ssh key permissions to have the `/etc/borgmatic/ssh_key` be readable by someone else - a (GUI) file manager, also rightly, won’t let you run it as root ### borgmatic version 1.8.3 ### borgmatic installation method EndeavourOS / Arch Linux package, using Yay ### Borg version borg 1.2.6 ### Python version Python 3.11.5 ### Database version (if applicable) _No response_ ### Operating system and version ```toml NAME="EndeavourOS" PRETTY_NAME="EndeavourOS" ID="endeavouros" ID_LIKE="arch" BUILD_ID="2023.08.05" ANSI_COLOR="38;2;23;147;209" HOME_URL="https://endeavouros.com" DOCUMENTATION_URL="https://discovery.endeavouros.com" SUPPORT_URL="https://forum.endeavouros.com" BUG_REPORT_URL="https://forum.endeavouros.com/c/arch-based-related-questions/bug-reports" PRIVACY_POLICY_URL="https://endeavouros.com/privacy-policy-2" LOGO="endeavouros" ```

witten commented

2023-10-16 16:46:52 +00:00

Thanks for making it all the way to the issue tracker! My thoughts on this:

Mounting an archive as a non-root user

For this approach, yeah, the only way that would work is if you gave that user access to all borgmatic configuration and credentials (e.g. SSH keys) needed to mount the repository. For the SSH keys, I wouldn't recommend using root's SSH keys. Rather, I'd suggest using the user's own SSH keys, first copying them into the Borg server's authorized_keys file (just like you presumably did for root's SSH keys already) so that the non-root user can access the remote Borg repository.

As for Can't determine which repository to use. Use --repository to disambiguate, maybe non-root borgmatic is using a different set of configuration files? You can increase the verbosity with --verbosity 2 which should tell you what configuration files it's trying to read. And then you can always give it a --config flag on the command-line to select a particular config file, ideally the same one root is using. Of course, the non-root user will need at least read access to that configuration file for this to work.

Major caveat: If the files within the archives have permissions that the non-root user cannot read, then it may be the case that even with all of the above working properly, you still won't be able to read these individual files as a non-root user. If that's the case, perhaps consider the other approach below.

Accessing a root-mounted archive as a non-root user

This is "just" a permission issue. So when you run ls -ld on the path of the root-mounted archive, what do you see? Similarly, if you mount with borgmatic mount --options uid=1000,gid=2000,allow_other=true ... where 1000 is the uid of your non-root user and 2000 is its gid, then what does ls -ld show you? Note that these options will cause all archived files to "change" their apparent owner and group as viewed through your mount. Which might be exactly what you want so you can access them as a non-root user. But I'm bringing it up because it's not technically an accurate view of the archive.

More details here: https://borgbackup.readthedocs.io/en/stable/usage/mount.html#description

Thanks for making it all the way to the issue tracker! My thoughts on this: ### Mounting an archive as a non-root user For this approach, yeah, the only way that would work is if you gave that user access to all borgmatic configuration and credentials (e.g. SSH keys) needed to mount the repository. For the SSH keys, I wouldn't recommend using root's SSH keys. Rather, I'd suggest using the user's own SSH keys, first copying them into the Borg server's `authorized_keys` file (just like you presumably did for root's SSH keys already) so that the non-root user can access the remote Borg repository. As for ```Can't determine which repository to use. Use --repository to disambiguate```, maybe non-root borgmatic is using a different set of configuration files? You can increase the verbosity with `--verbosity 2` which should tell you what configuration files it's trying to read. And then you can always give it a `--config` flag on the command-line to select a particular config file, ideally the same one root is using. Of course, the non-root user will need at least read access to that configuration file for this to work. Major caveat: If the files within the archives have permissions that the non-root user cannot read, then it may be the case that even with all of the above working properly, you still won't be able to read these individual files as a non-root user. If that's the case, perhaps consider the other approach below. ### Accessing a root-mounted archive as a non-root user This is "just" a permission issue. So when you run `ls -ld` on the path of the root-mounted archive, what do you see? Similarly, if you mount with `borgmatic mount --options uid=1000,gid=2000,allow_other=true ...` where `1000` is the uid of your non-root user and 2000 is its gid, then what does `ls -ld` show you? Note that these options will cause all archived files to "change" their apparent owner and group as viewed through your mount. Which might be exactly what you want so you can access them as a non-root user. But I'm bringing it up because it's not technically an accurate view of the archive. More details here: https://borgbackup.readthedocs.io/en/stable/usage/mount.html#description

witten added the

question / support

label 2023-10-16 16:46:57 +00:00

hook commented

2023-10-16 22:39:59 +00:00

Non-root access

I tried to fix this by chgrp --recursive backup /etc/borgmatic and adding my normal user to that group and then running borgmatic as normal user. (I reverted that since, of course.)

The result was that Borg(matic)/SSH did not want to continue because of the key permissions.

I guess I could just keep two copies of the settings and two different keys, but that sounds silly and asking for PEBKAC-triggered errors after some time has passed and I forget it.

Mount options

sudo borgmatic mount --verbosity 2 --mount-point /home/hook/tmp_mount --options uid=1000,gid=1000 (fuse complains that allow_other=true is not a valid option, and I used the correct gid here) produces:

borg --version --debug --show-rc
backupserver: Running actions for repository
/etc/borgmatic/config.yaml: No commands to run for pre-actions hook
backupserver: Mounting repository
borg mount --debug --show-rc -o uid=1000,gid=1000 ssh://{$redacted}/./leza /home/hook/tmp_mount
using builtin fallback logging configuration
33 self tests completed in 0.04 seconds
SSH command line: ['ssh', '-p', '22111', '-i', '/etc/borgmatic/backup_na_kalipso', '{$redacted}', 'borg', 'serve', '--debug']
Remote: using builtin fallback logging configuration
Remote: 35 self tests completed in 1.44 seconds
Remote: using builtin fallback logging configuration
Remote: Initialized logging system for JSON-based protocol
Remote: Resolving repository path b'/./leza'
Remote: Resolved repository path to '/home/backup/repos/leza'
Remote: Verified integrity of /home/backup/repos/leza/index.350
TAM-verified manifest
security: read previous location 'ssh://{$redacted}/./leza'
security: read manifest timestamp '2023-10-16T10:13:12.438671'
security: determined newest manifest timestamp as 2023-10-16T10:13:12.438671
security: repository checks ok, allowing access
mount data cache capacity: 16 chunks
Mounting filesystem
Initializing llfuse
Calling fuse_mount
Calling fuse_lowlevel_new
Calling fuse_session_add_chan
Daemonizing: Foreground process (leza@215656230228522, 172933, 0) is now dying.
/etc/borgmatic/config.yaml: No commands to run for post-actions hook

summary:
/etc/borgmatic/config.yaml: Loading configuration file
/etc/borgmatic/config.yaml: Successfully ran configuration file

ls tmp_mount:

ls: tmp_mount: Permission denied (os error 13).

ls tmp_mount/leza-2023-10-11T08:27:12.557499/home/hook/ – at least the home folder should be accessible by its user though:

ls: tmp_mount/leza-2023-10-11T08:27:12.557499/home/hook/: Permission denied (os error 13).

Alternative approach: two separate backups?

Maybe the most elegant solution would be to have two separate backups:

one for my home, running as the normal user, using the user systemd unit
the second one for the system stuff, running as root, using the system systemd unit

Thoughts?

# Non-root access I tried to fix this by `chgrp --recursive backup /etc/borgmatic` and adding my normal user to that group and then running borgmatic as normal user. (I reverted that since, of course.) The result was that Borg(matic)/SSH did not want to continue because of the key permissions. I guess I could just keep two copies of the settings and two different keys, but that sounds silly and asking for PEBKAC-triggered errors after some time has passed and I forget it. # Mount options `sudo borgmatic mount --verbosity 2 --mount-point /home/hook/tmp_mount --options uid=1000,gid=1000` (fuse complains that `allow_other=true` is not a valid option, and I used the correct gid here) produces: ``` borg --version --debug --show-rc backupserver: Running actions for repository /etc/borgmatic/config.yaml: No commands to run for pre-actions hook backupserver: Mounting repository borg mount --debug --show-rc -o uid=1000,gid=1000 ssh://{$redacted}/./leza /home/hook/tmp_mount using builtin fallback logging configuration 33 self tests completed in 0.04 seconds SSH command line: ['ssh', '-p', '22111', '-i', '/etc/borgmatic/backup_na_kalipso', '{$redacted}', 'borg', 'serve', '--debug'] Remote: using builtin fallback logging configuration Remote: 35 self tests completed in 1.44 seconds Remote: using builtin fallback logging configuration Remote: Initialized logging system for JSON-based protocol Remote: Resolving repository path b'/./leza' Remote: Resolved repository path to '/home/backup/repos/leza' Remote: Verified integrity of /home/backup/repos/leza/index.350 TAM-verified manifest security: read previous location 'ssh://{$redacted}/./leza' security: read manifest timestamp '2023-10-16T10:13:12.438671' security: determined newest manifest timestamp as 2023-10-16T10:13:12.438671 security: repository checks ok, allowing access mount data cache capacity: 16 chunks Mounting filesystem Initializing llfuse Calling fuse_mount Calling fuse_lowlevel_new Calling fuse_session_add_chan Daemonizing: Foreground process (leza@215656230228522, 172933, 0) is now dying. /etc/borgmatic/config.yaml: No commands to run for post-actions hook summary: /etc/borgmatic/config.yaml: Loading configuration file /etc/borgmatic/config.yaml: Successfully ran configuration file ``` `ls tmp_mount`: ``` ls: tmp_mount: Permission denied (os error 13). ``` `ls tmp_mount/leza-2023-10-11T08:27:12.557499/home/hook/` – at least the home folder should be accessible by its user though: ``` ls: tmp_mount/leza-2023-10-11T08:27:12.557499/home/hook/: Permission denied (os error 13). ``` # Alternative approach: two separate backups? Maybe the most elegant solution would be to have two separate backups: - one for my home, running as the normal user, using the user systemd unit - the second one for the system stuff, running as root, using the system systemd unit Thoughts?

witten commented

2023-10-17 17:19:03 +00:00

I guess I could just keep two copies of the settings and two different keys, but that sounds silly and asking for PEBKAC-triggered errors after some time has passed and I forget it.

Yeah, I understand that.

ls: tmp_mount/leza-2023-10-11T08:27:12.557499/home/hook/: Permission denied (os error 13).

Hmm.. I assume you're running ls here as the non-root user? Are you sure that 1000 and 1000 correspond to that user's ID and group ID, respectively? When you ls -ld on the directory (or a parent directory if you don't have permissions to ls that one), what are the permissions and ownership shown on the files?

Maybe the most elegant solution would be to have two separate backups:

That would certainly work, and would sidestep many of these permissions issues. The main challenge is that it might be a little more inconvenient, so it's your call whether that's worth it!

> I guess I could just keep two copies of the settings and two different keys, but that sounds silly and asking for PEBKAC-triggered errors after some time has passed and I forget it. Yeah, I understand that. > ls: tmp_mount/leza-2023-10-11T08:27:12.557499/home/hook/: Permission denied (os error 13). Hmm.. I assume you're running `ls` here as the non-root user? Are you sure that 1000 and 1000 correspond to that user's ID and group ID, respectively? When you `ls -ld` on the directory (or a parent directory if you don't have permissions to `ls` that one), what are the permissions and ownership shown on the files? > Maybe the most elegant solution would be to have two separate backups: That would certainly work, and would sidestep many of these permissions issues. The main challenge is that it might be a little more inconvenient, so it's your call whether that's worth it!

hook commented

2023-10-17 17:46:32 +00:00

Hmm.. I assume you're running ls here as the non-root user?

Yes.

Are you sure that 1000 and 1000 correspond to that user's ID and group ID, respectively?

Yes.

id says:

uid=1000(hook) gid=1000(hook) groups=1000(hook),19(log),50(games),982(rfkill),984(users),998(wheel),1001(roccat)

When you ls -ld on the directory (or a parent directory if you don't have permissions to ls that one), what are the permissions and ownership shown on the files?

ls -ld /home/hook:

drwxr-xr-x 1 hook hook 1018 okt 17 17:33 .

ls -ld /home/hook/tmp_mount/:

ls: /home/hook/tmp_mount: Permission denied (os error 13).

ls -ld /home/hook/tmp_mount/leza-2023-10-11T08:27:12.557499/home/hook/:

ls: /home/hook/tmp_mount/leza-2023-10-11T08:27:12.557499/home/hook/: Permission denied (os error 13).

Maybe the most elegant solution would be to have two separate backups:

That would certainly work, and would sidestep many of these permissions issues. The main challenge is that it might be a little more inconvenient, so it's your call whether that's worth it!

I’ll keep it in mind as a backup (ha!) plan then :)

> Hmm.. I assume you're running `ls` here as the non-root user? Yes. > Are you sure that 1000 and 1000 correspond to that user's ID and group ID, respectively? Yes. `id` says: ``` uid=1000(hook) gid=1000(hook) groups=1000(hook),19(log),50(games),982(rfkill),984(users),998(wheel),1001(roccat) ``` > When you `ls -ld` on the directory (or a parent directory if you don't have permissions to `ls` that one), what are the permissions and ownership shown on the files? `ls -ld /home/hook`: ``` drwxr-xr-x 1 hook hook 1018 okt 17 17:33 . ``` `ls -ld /home/hook/tmp_mount/`: ``` ls: /home/hook/tmp_mount: Permission denied (os error 13). ``` `ls -ld /home/hook/tmp_mount/leza-2023-10-11T08:27:12.557499/home/hook/`: ``` ls: /home/hook/tmp_mount/leza-2023-10-11T08:27:12.557499/home/hook/: Permission denied (os error 13). ``` > > Maybe the most elegant solution would be to have two separate backups: > > That would certainly work, and would sidestep many of these permissions issues. The main challenge is that it might be a little more inconvenient, so it's your call whether that's worth it! I’ll keep it in mind as a backup (ha!) plan then :)

witten commented

2023-10-17 18:03:42 +00:00

And when you ls those same directories as the root user, what permissions/ownership do you see?

And when you `ls` those same directories as the root user, what permissions/ownership do you see?

hook commented

2023-10-17 18:16:20 +00:00

drwxr-xr-x 1 hook hook 1018 okt 17 17:33 /home/hook/

drwxr-xr-x 1 hook hook 0 okt 17 19:41 /home/hook/tmp_mount/

drwx------ 1 hook hook 0 okt 10 10:41 /home/hook/tmp_mount/leza-2023-10-11T08:27:12.557499/home/hook/

P.S. Thank you for taking the time to help me with this.

``` drwxr-xr-x 1 hook hook 1018 okt 17 17:33 /home/hook/ ``` ``` drwxr-xr-x 1 hook hook 0 okt 17 19:41 /home/hook/tmp_mount/ ``` ``` drwx------ 1 hook hook 0 okt 10 10:41 /home/hook/tmp_mount/leza-2023-10-11T08:27:12.557499/home/hook/ ``` P.S. Thank you for taking the time to help me with this.

witten commented

2023-10-17 18:30:01 +00:00

That's really odd, because it's indeed showing up as owned by your user, so I would not expect that to result in permission errors! Unfortunately this is getting beyond my FUSE expertise. The only other thing I would suggest is to add ,allow_other to your mount options and try again. If that doesn't work, then maybe consider filing a Borg ticket? I looked through various issues in the Borg backlog, and while I did find similar symptoms to what you're experiencing, I didn't find any clear solutions.

In order to reproduce this with just Borg and without borgmatic, you can run the borg mount command that shows up in borgmatic's verbose output:

borg mount --debug --show-rc -o uid=1000,gid=1000 ssh://{$redacted}/./leza /home/hook/tmp_mount

That's really odd, because it's indeed showing up as owned by your user, so I would not expect that to result in permission errors! Unfortunately this is getting beyond my FUSE expertise. The only other thing I would suggest is to add `,allow_other` to your mount options and try again. If that doesn't work, then maybe consider filing a Borg ticket? I looked through various issues in the Borg backlog, and while I did find similar symptoms to what you're experiencing, I didn't find any clear solutions. In order to reproduce this with just Borg and without borgmatic, you can run the `borg mount` command that shows up in borgmatic's verbose output: ```borg mount --debug --show-rc -o uid=1000,gid=1000 ssh://{$redacted}/./leza /home/hook/tmp_mount```

hook commented

2023-10-17 18:54:29 +00:00

In order to reproduce this with just Borg and without borgmatic, you can run the borg mount command that shows up in borgmatic's verbose output:

borg mount --debug --show-rc -o uid=1000,gid=1000 ssh://{$redacted}/./leza /home/hook/tmp_mount

This command I can successfully run as normal user (I guess because I have a ssh key to that server also in my ~/.ssh/). All I had to do was enter the remote repository’s password when asked. All other commands in this comment are also as normal user.

using builtin fallback logging configuration
33 self tests completed in 0.05 seconds
SSH command line: ['ssh', '{$redacted}, 'borg', 'serve', '--debug']
Remote: using builtin fallback logging configuration
Remote: 35 self tests completed in 1.45 seconds
Remote: using builtin fallback logging configuration
Remote: Initialized logging system for JSON-based protocol
Remote: Resolving repository path b'/./leza'
Remote: Resolved repository path to '/home/backup/repos/leza'
Remote: Verified integrity of /home/backup/repos/leza/index.362
Enter passphrase for key ssh://{$redacted}/./leza: 
TAM-verified manifest
security: read previous location 'ssh://{$redacted}/./leza'
security: read manifest timestamp '2023-09-29T19:20:49.184981'
security: determined newest manifest timestamp as 2023-09-29T19:20:49.184981
security: repository checks ok, allowing access
mount data cache capacity: 16 chunks
Mounting filesystem
Initializing llfuse
Calling fuse_mount
Calling fuse_lowlevel_new
Calling fuse_session_add_chan
Daemonizing: Foreground process (leza@215656230228522, 210758, 0) is now dying.

and ls /hook/home/tmp_mount/ also produces:

 leza-2023-09-16T23:01:22.933288   leza-2023-09-30T20:50:05.394008   leza-2023-10-09T10:06:36.718132   leza-2023-10-12T08:32:01.022723   leza-2023-10-16T11:55:19.405271
 leza-2023-09-17T13:38:10.995471   leza-2023-10-01T00:34:47.726185   leza-2023-10-10T06:54:37.290504   leza-2023-10-13T00:11:37.660551   leza-2023-10-17T08:06:25.751201
 leza-2023-09-21T00:02:06.464709   leza-2023-10-05T00:55:53.091051   leza-2023-10-11T08:27:12.557499   leza-2023-10-15T02:17:57.646966

Further in, I can also ls /hook/home/tmp_mount/leza-2023-10-15T0217:57.646966:

 etc   home   root

Even more, I can even ls /hook/home/tmp_mount/leza-2023-10-15T0217:57.646966/root successfully as normal user!

So I took this experiment further and if I omit the -o uid, gid part, it gets even better!

borg mount --debug --show-rc ssh://{$redacted}/./leza /home/hook/tmp_mount/

using builtin fallback logging configuration
33 self tests completed in 0.04 seconds
SSH command line: ['ssh', '{$redacted}', 'borg', 'serve', '--debug']
Remote: using builtin fallback logging configuration
Remote: 35 self tests completed in 1.45 seconds
Remote: using builtin fallback logging configuration
Remote: Initialized logging system for JSON-based protocol
Remote: Resolving repository path b'/./leza'
Remote: Resolved repository path to '/home/backup/repos/leza'
Remote: Verified integrity of /home/backup/repos/leza/index.362
Enter passphrase for key ssh://{$redacted}/./leza: 
TAM-verified manifest
security: read previous location 'ssh://{$redacted}/./leza'
security: read manifest timestamp '2023-09-29T19:20:49.184981'
security: determined newest manifest timestamp as 2023-09-29T19:20:49.184981
security: repository checks ok, allowing access
mount data cache capacity: 16 chunks
Mounting filesystem
Initializing llfuse
Calling fuse_mount
Calling fuse_lowlevel_new
Calling fuse_session_add_chan
Daemonizing: Foreground process (leza@215656230228522, 211204, 0) is now dying.

ls -la tmp_mount/leza-2023-09-16T23:01:22.933288/:

drwxr-xr-x root root 0 B Sat Sep 16 22:21:41 2023  etc
drwxr-xr-x root root 0 B Sun Sep  3 02:23:45 2023  home
drwxr-xr-x hook hook 0 B Tue Oct 17 20:51:10 2023  root

> In order to reproduce this with just Borg and without borgmatic, you can run the `borg mount` command that shows up in borgmatic's verbose output: > > ```borg mount --debug --show-rc -o uid=1000,gid=1000 ssh://{$redacted}/./leza /home/hook/tmp_mount``` This command I can successfully run as normal user (I guess because I have a ssh key to that server also in my `~/.ssh/`). All I had to do was enter the remote repository’s password when asked. All other commands in this comment are also as normal user. ``` using builtin fallback logging configuration 33 self tests completed in 0.05 seconds SSH command line: ['ssh', '{$redacted}, 'borg', 'serve', '--debug'] Remote: using builtin fallback logging configuration Remote: 35 self tests completed in 1.45 seconds Remote: using builtin fallback logging configuration Remote: Initialized logging system for JSON-based protocol Remote: Resolving repository path b'/./leza' Remote: Resolved repository path to '/home/backup/repos/leza' Remote: Verified integrity of /home/backup/repos/leza/index.362 Enter passphrase for key ssh://{$redacted}/./leza: TAM-verified manifest security: read previous location 'ssh://{$redacted}/./leza' security: read manifest timestamp '2023-09-29T19:20:49.184981' security: determined newest manifest timestamp as 2023-09-29T19:20:49.184981 security: repository checks ok, allowing access mount data cache capacity: 16 chunks Mounting filesystem Initializing llfuse Calling fuse_mount Calling fuse_lowlevel_new Calling fuse_session_add_chan Daemonizing: Foreground process (leza@215656230228522, 210758, 0) is now dying. ``` and `ls /hook/home/tmp_mount/` also produces: ```  leza-2023-09-16T23:01:22.933288  leza-2023-09-30T20:50:05.394008  leza-2023-10-09T10:06:36.718132  leza-2023-10-12T08:32:01.022723  leza-2023-10-16T11:55:19.405271  leza-2023-09-17T13:38:10.995471  leza-2023-10-01T00:34:47.726185  leza-2023-10-10T06:54:37.290504  leza-2023-10-13T00:11:37.660551  leza-2023-10-17T08:06:25.751201  leza-2023-09-21T00:02:06.464709  leza-2023-10-05T00:55:53.091051  leza-2023-10-11T08:27:12.557499  leza-2023-10-15T02:17:57.646966 ``` Further in, I can also `ls /hook/home/tmp_mount/leza-2023-10-15T0217:57.646966`: ```  etc  home  root ``` Even more, I can even `ls /hook/home/tmp_mount/leza-2023-10-15T0217:57.646966/root` successfully as normal user! --- So I took this experiment further and if I omit the `-o uid, gid` part, it gets even better! `borg mount --debug --show-rc ssh://{$redacted}/./leza /home/hook/tmp_mount/` ``` using builtin fallback logging configuration 33 self tests completed in 0.04 seconds SSH command line: ['ssh', '{$redacted}', 'borg', 'serve', '--debug'] Remote: using builtin fallback logging configuration Remote: 35 self tests completed in 1.45 seconds Remote: using builtin fallback logging configuration Remote: Initialized logging system for JSON-based protocol Remote: Resolving repository path b'/./leza' Remote: Resolved repository path to '/home/backup/repos/leza' Remote: Verified integrity of /home/backup/repos/leza/index.362 Enter passphrase for key ssh://{$redacted}/./leza: TAM-verified manifest security: read previous location 'ssh://{$redacted}/./leza' security: read manifest timestamp '2023-09-29T19:20:49.184981' security: determined newest manifest timestamp as 2023-09-29T19:20:49.184981 security: repository checks ok, allowing access mount data cache capacity: 16 chunks Mounting filesystem Initializing llfuse Calling fuse_mount Calling fuse_lowlevel_new Calling fuse_session_add_chan Daemonizing: Foreground process (leza@215656230228522, 211204, 0) is now dying. ``` `ls -la tmp_mount/leza-2023-09-16T23:01:22.933288/`: ``` drwxr-xr-x root root 0 B Sat Sep 16 22:21:41 2023  etc drwxr-xr-x root root 0 B Sun Sep 3 02:23:45 2023  home drwxr-xr-x hook hook 0 B Tue Oct 17 20:51:10 2023  root ```

witten commented

2023-10-17 19:11:06 +00:00

Very cool! So it sounds like then mounting as a non-root user without borgmatic is the way to go? That is unless you want to change the permissions on the borgmatic config so that all users can read it.

hook commented

2023-10-17 19:39:50 +00:00

borg mount would work for me, but from a user PoV it does seem odd to use one tool to do everything, and another to

Again, works for me and I’m not complaining, but it does feel like more like a workaround.

`borg mount ` would work for me, but from a user PoV it does seem odd to use one tool to do everything, and another to Again, works for me and I’m not complaining, but it does feel like more like a workaround.

witten commented

2023-10-17 19:43:49 +00:00

Agreed. If you'd like to use borgmatic for this task, then I'd suggest adjusting the permissions on your borgmatic configuration file so it's readable by your user account. And then specify a --config path or rely on the default configuration probing. If you're still getting Can't determine which repository to use, then perhaps look at the logs to see what configuration files it's using.

Agreed. If you'd like to use borgmatic for this task, then I'd suggest adjusting the permissions on your borgmatic configuration file so it's readable by your user account. And then specify a `--config` path or rely on the default configuration probing. If you're still getting `Can't determine which repository to use`, then perhaps look at the logs to see what configuration files it's using.

hook commented

2023-10-18 19:56:09 +00:00

@witten , how do I get around the issue that /etc/borgmatic/config.yaml points to /etc/borgmatic/ssh_key then?

@witten , how do I get around the issue that `/etc/borgmatic/config.yaml` points to `/etc/borgmatic/ssh_key` then?

witten commented

2023-10-18 20:04:15 +00:00

Good question. You could put the key in each user's home directory (e.g. in the traditional location in ~/.ssh) and then refer to it by a path that resolves to a different actual location for each user. E.g. ~/.ssh/ssh_key would resolve to /root/.ssh/ssh_key when run as the root user and /home/hook/.ssh/ssh_key or whatever when run as the non-root user.

Another option would be to use borgmatic configuration includes to reuse common configuration while still overriding different per-user configuration.

Yet a third option would be to not set the SSH key path in borgmatic's configuration file and instead specify it some other way (~/.ssh/config, etc.).

Good question. You could put the key in each user's home directory (e.g. in the traditional location in `~/.ssh`) and then refer to it by a path that resolves to a different actual location for each user. E.g. `~/.ssh/ssh_key` would resolve to `/root/.ssh/ssh_key` when run as the root user and `/home/hook/.ssh/ssh_key` or whatever when run as the non-root user. Another option would be to use borgmatic [configuration includes](https://torsion.org/borgmatic/docs/how-to/make-per-application-backups/#configuration-includes) to reuse common configuration while still overriding different per-user configuration. Yet a third option would be to not set the SSH key path in borgmatic's configuration file and instead specify it some other way ([`~/.ssh/config`](https://linuxize.com/post/using-the-ssh-config-file/), etc.).

witten commented

2023-12-23 02:40:27 +00:00

I'm closing this one for now, but feel free to comment or open a new ticket if there's anything else! Thanks.

witten closed this issue

2023-12-23 02:40:27 +00:00

Sign in to join this conversation.