error: attribute 'homepage' missing
at ~/src/nixpkgs/pkgs/os-specific/linux/fuse/common.nix:91:21:
90|
91| meta = with lib; {
| ^
92| description = "Library that allows filesystems to be implemented in user space";
when mounting a fuse fs by fstab on can write:
/nix/store/sdlflj/bin/somefuseexe#argument /mountpoint fuse setuid=someuser
mount is run by root, and setuid is a way to tell mount.fuse to run
somefuseexe as someuser instead. Under the hood, mount.fuse uses su.
The problem is that mount is run by systemd in a seemingly very empty
environment not containing /run/current-system/sw/bin nor
/run/wrappers/bin in $PATH, so mount fails with "su command not found".
We now patch the command to run su with an absolute path.
man mount.fuse3 indicates that this option is reserved to root (or with
enough capabilities) so not using
/run/wrappers/bin/su is thus correct. It has the very small advantage of
possibly working on non nixos.
Do not set FUSERMOUNT_DIR since we already set it though
NIX_CFLAGS_COMPILE.
Setting it twice results in a lot of warnings like this one:
<command-line>:0:0: warning: "FUSERMOUNT_DIR" redefined
which makes the build look potentially broken.
This doesn't affect the result but fuse3 will now build without any
warnings and building fuse yields less warnings.
This includes fuse-common (fusePackages.fuse_3.common) as recommended by
upstream. But while fuse(2) and fuse3 would normally depend on
fuse-common we can't do that in nixpkgs while fuse-common is just
another output from the fuse3 multiple-output derivation (i.e. this
would result in a circular dependency). To avoid building fuse3 twice I
decided it would be best to copy the shared files (i.e. the ones
provided by fuse(2) and fuse3) from fuse-common to fuse (version 2) and
avoid collision warnings by defining priorities. Now it should be
possible to install an arbitrary combination of "fuse", "fuse3", and
"fuse-common" without getting any collision warnings. The end result
should be the same and all changes should be backwards compatible
(assuming that mount.fuse from fuse3 is backwards compatible as stated
by upstream [0] - if not this might break some /etc/fstab definitions
but that should be very unlikely).
My tests with sshfs (version 2 and 3) didn't show any problems.
See #28409 for some additional information.
[0]: https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0
