BORG-MOUNT(1) | borg backup tool | BORG-MOUNT(1) |
borg-mount - Mount archive or an entire repository as a FUSE filesystem
borg [common options] mount [options] MOUNTPOINT [PATH...]
This command mounts an archive as a FUSE filesystem. This can be useful for browsing an archive or restoring individual files. When restoring, take into account that the current FUSE implementation does not support special fs flags and ACLs.
Unless the --foreground option is given the command will run in the background until the filesystem is umounted.
The command borgfs provides a wrapper for borg mount. This can also be used in fstab entries: /path/to/repo /mnt/point fuse.borgfs defaults,noauto 0 0
To allow a regular user to use fstab entries, add the user option: /path/to/repo /mnt/point fuse.borgfs defaults,noauto,user 0 0
For FUSE configuration and mount options, see the mount.fuse(8) manual page.
Borg's default behavior is to use the archived user and group names of each file and map them to the system's respective user and group ids. Alternatively, using numeric-ids will instead use the archived user and group ids without any mapping.
The uid and gid mount options (implemented by Borg) can be used to override the user and group ids of all files (i.e., borg mount -o uid=1000,gid=1000).
The man page references user_id and group_id mount options (implemented by fuse) which specify the user and group id of the mount owner (aka, the user who does the mounting). It is set automatically by libfuse (or the filesystem if libfuse is not used). However, you should not specify these manually. Unlike the uid and gid mount options which affect all files, user_id and group_id affect the user and group id of the mounted (base) directory.
Additional mount options supported by borg:
The BORG_MOUNT_DATA_CACHE_ENTRIES environment variable is meant for advanced users to tweak the performance. It sets the number of cached data chunks; additional memory usage can be up to ~8 MiB times this number. The default is the number of CPU cores.
When the daemonized process receives a signal or crashes, it does not unmount. Unmounting in these cases could cause an active rsync or similar process to delete data unintentionally.
When running in the foreground ^C/SIGINT unmounts cleanly, but other signals or crashes do not.
See borg-common(1) for common options of Borg commands.
The Borg Collective
2023-03-01 |