fuservicemount as a systemd storage provider

fuservicemount as a systemd storage provider

[Skye Soss]

The fuservicemount infrastructure that's currently being developed in the libfuse repository allows an administrator to
setup a service that can create sandboxed filesystem implementations on-demand.

There is a very similar interface that's being developed in systemd (added in 261) called Storage Providers[1].
The directory /run/systemd/io.systemd.StorageProvider/ contains Unix domain sockets, each of which is backed by a Varlink
service. The interface (modulo metadata + options) is essentially:

Acquire(name: string) -> (fileDescriptor: int)

systemd also provides a mount helper so that `mount -t storage` can transparently use the storage provider interface.

This seems like a very similar kind of setup to fuservicemount + mount.fuse, and I'm curious if there's anything missing
from the systemd interface that would stop fuservicemount from being implement in those terms.
I believe that systemd-nspawn and systemd-vmspawn are going to be extended to create mounts from these interfaces, so
compatibility would be useful.

[1]: https://www.freedesktop.org/software/systemd/man/latest/systemd-storage-fs@.service.html

Re: fuservicemount as a systemd storage provider

[Darrick J. Wong]

On Sun, Sep 20, 2026 at 02:01:48PM -0500, Skye Soss wrote:
> The fuservicemount infrastructure that's currently being developed in the libfuse repository allows an administrator to
> setup a service that can create sandboxed filesystem implementations on-demand.
> 
> There is a very similar interface that's being developed in systemd (added in 261) called Storage Providers[1].
> The directory /run/systemd/io.systemd.StorageProvider/ contains Unix domain sockets, each of which is backed by a Varlink
> service. The interface (modulo metadata + options) is essentially:
> 
> Acquire(name: string) -> (fileDescriptor: int)
> 
> systemd also provides a mount helper so that `mount -t storage` can transparently use the storage provider interface.
> 
> This seems like a very similar kind of setup to fuservicemount + mount.fuse, and I'm curious if there's anything missing
> from the systemd interface that would stop fuservicemount from being implement in those terms.

Can't work on any environment that lacks systemd (Devuan, BSDs, etc)

--D

> I believe that systemd-nspawn and systemd-vmspawn are going to be extended to create mounts from these interfaces, so
> compatibility would be useful.
> 
> [1]: https://www.freedesktop.org/software/systemd/man/latest/systemd-storage-fs@.service.html
>