(ARM-based macs) make borg mount an alias to anylinuxfs mount to avoid using macFUSE

[fleetwoodmac]

After a few years of using a workaround method (github.com/fleetwoodmac/FUSEless-Mount-macOS), I came across a project by nohajc called anylinuxfs (https://github.com/nohajc/anylinuxfs)

the project is essentially a micro-vm running alpine that mounts a linux filesystem and exposes it to the host Mac via an NFS share. This avoids all the weird was in which FUSE-T was trying to map FUSE bindings to NFS bindings (not to mentioned that it is still closed source).

anylinuxfs is already being used by people in the community to mount local linux filesystems that had a borg repo to be able to browse their backups. The maintainer was super nice and implemented the ability to mount remote filesystems as well (NFS/SMB, see nohajc/anylinuxfs#72).

you essentially can create a dummy img with dd, throw an ext4 filesystem on it with e2fsprogs, and then define an anylinuxfs 'custom action' that mounts your share (or your local device), runs borg mount which mounts it in the linux micro-vm, and then exposes it via an NFS share. I have been able to backup using vorta, and now am able to browse my backups without using macFUSE or FUSE-T. The custom action supports cleanup commands so that it can cleanly unmount your borg mount and your remote FS (or your local one).

All this runs in userspace so no need for kexts, and it's open source unlike fuse-t. Would it maybe be possible/of interest to make borg mount on macOS ARM devices an alias to this?

[ThomasWaldmann]

Interesting, didn't know that.

But if that is completely separate from the borg code on the host system (and in fact includes another borg in the linux system, potentially of a different version), what would be the point of wrapping it?

[ThomasWaldmann]

BTW:
"""
macFUSE is evolving beyond kernel extensions

Thanks to the new FSKit backend in macFUSE, supported file systems can now run entirely in user space on macOS 26. That means no more rebooting into recovery mode to enable support for the macFUSE kernel extension. Installation is faster and setup becomes a seamless experience.
"""

[fleetwoodmac]

Interesting, didn't know that.

But if that is completely separate from the borg code on the host system (and in fact includes another borg in the linux system, potentially of a different version), what would be the point of wrapping it?

i'm pretty far removed as a user, so apologies if this is off base; my understanding is that currently borg mount on the host system directly calls fuse on the host system which requires fuse to be installed on the host system. currently FUSE on macos requires either:

• macFUSE (kext which is not great for security per Apple and just generally exploitable)
• FUSE-T, userspace drop in replacement that aims to do FUSE -> NFS bindings translations to mount FUSE systems in kernel space (not super stable, closed source despite years-old maintainer promises)

the point of wrapping an anylinuxfs setup would be strictly to circumvent these issues on macos and seamlessly expose any local or remote borg repos to the host. would 100% encourage more casual users since vorta wraps borg mount from its GUI, so if this change was made it would be great to just have it mount without having to tell users to install a kext or mess with trying to figure out where to dump fuse-t's files

and for the versioning thing, anylinuxfs can add any packages to the microVM via anylinuxfs apk add so during some initial setup wrapped by borg, you can just specify what versions of the alpine packages to download to keep everything equivalent to the borg version that is managing it; this could be done declaratively to avoid any user issues (or via some setup script maybe)

BTW: """ macFUSE is evolving beyond kernel extensions

Thanks to the new FSKit backend in macFUSE, supported file systems can now run entirely in user space on macOS 26. That means no more rebooting into recovery mode to enable support for the macFUSE kernel extension. Installation is faster and setup becomes a seamless experience. """

I actually hadn't heard about how far this had gotten. Looks like cryptomator is trying to pursue along with some other projects here but looks like there is a long road to go (like this developer documenting their usage

The FSKit route would be great, but this is a pretty good 'middle ground' until that is fully supported in my view.

Maybe it would be cool to support this as a mounting 'backend' alternative to fuse on the host system? like borg mount --mount-method=anylinuxfs gives the user at least some options similar to how Kopia implements a WebDAV method of exposing a repo without using FUSE?

[ThomasWaldmann]

I understood why some users may want to use anylinuxfs.

But I still see no point in wrapping it via borg:

• you can just use it directly without that wrapper
• it would create a platform-dependent dependency on some relatively large and complex blob
• i only want to provide support for borg, not for anylinuxfs issues

[fleetwoodmac]

Fair enough--I guess at the very least it would be cool to have the option to allow someone to create a custom borg mount action or backend that you can specify so that borg mount just calls whatever you define for macOS arm devices. could just be a flag you supply with mount like --custom-mount-action or --mount-method=custom /path/to/script or whatever that completely overrides the default fuse method.

that way you dont have to wrap anything or have any additional deps or provide support, and just leave it to the user to figure out that stuff

but maybe it's just better have the community supply and maintain a custom mount script and only use the host borg instance for creating backups and doing maintenance operations. Just wanted to suggest it as an option for what has been a huge inconvenience for arm users

[fleetwoodmac]

hi @ThomasWaldmann

just wanted to follow up with you to see if something like this would be in scope of what you would want to see in borg. if not absolutely no worries, just want to know whether or not to close this issue because I don't want it to be a burden for you/sit open as an issue

[ThomasWaldmann]

What I could imagine is something very simple:

• borg mount ... could invoke borg-wrapper mount ...
• borg umount ... could invole borg-wrapper umount ...

That way, tools above borg (like vorta) would not need to know about the fuse implementation and would not need to use different commands depending on the implementation.

We already have a BORG_FUSE_IMPL env var that tells borg about which fuse implementations to use (currently: mfusepy,pyfuse3,llfuse in master branch).

That could grow another implementation option (e.g. wrapper) that just invokes the wrapper as a subprocess.

Everything else needed would be the task of that wrapper, which would not be part of the borg project (but could be part of a repo in the borgbackup org, if somebody wants to implement and maintain it).

Alternatively:

Basically the same idea, but not with a shell command, but a python library.