[ifnotcode]

Why

dfuse --allow-idmap (#19404) lets containers in user namespaces use dfuse mounts. It needs
FUSE_CAP_ALLOW_IDMAP, for example for Kubernetes pods with hostUsers: false.

• Upstream libfuse has the flag since
  1f4c0608,
  which is not in a release yet.
• fused v1.0.0 (a libfuse snapshot before 3.17) cannot express it. The flag is bit 32 of the
  capabilities, and libfuse only has 64-bit capabilities from 3.17 on (want_ext, set with
  fuse_set_feature_flag()). Bit 31, the last one of the 32-bit field, is
  FUSE_CAP_OVER_IO_URING upstream.

Without this PR, --allow-idmap has no effect: dfuse only logs that the fuse library does not
support idmapped mounts. #19404 can be merged before or without this PR.

Change

• Update fused to v1.1.0 (libfuse 3.17.4).
• Carry the libfuse change in deps/patches/fused, the way patches for mercury, spdk and
  argobots are carried. Both patches keep the upstream author and commit message.
  • 0001_fuse_kernel_h_linux_6.14.patch:
    d393ffa8 "Synchronize fuse_kernel.h with
    linux-6.14". It adds FUSE_ALLOW_IDMAP and cherry-picks onto v1.1.0 without conflicts; the
    patch is the export of that cherry-pick, so only its hunk offsets differ from the commit.
  • 0002_fuse_cap_allow_idmap.patch: 1f4c0608 "add FUSE_CAP_ALLOW_IDMAP (DAOS-2185 continer: fix for snapshot creation #1446)", backported
    to 3.17.4. The note at the end of its commit message describes the backport:
    • The context of both fuse_lowlevel.c hunks differs. The io-uring lines next to the first
      one are left out, because 3.17 has no io-uring support.
    • The second hunk stays before FUSE_INIT_EXT is handled, as upstream. Otherwise the flag
      would not reach flags2.
• Packaging: fused-devel 1.1.0-1, BuildRequires: fused-devel >= 1.1.0 (dfuse's #ifdef
  would otherwise silently drop the option in a build against an older fused-devel), daos
  2.9.100-9, and changelogs. The release goes from 7 to 9 because the changelog on master already
  has 2.9.100-8 (DAOS-19763) while daos.spec still says 7.

The flag is only sent to the kernel when a filesystem requests it, so nothing changes unless dfuse
is started with --allow-idmap. The patches can be dropped once fused or upstream libfuse has the
change (DAOS-18222, daos-stack/fused#11). If it goes into fused itself: the v1.1.0 tag still
carries fused.spec and debian/changelog at 1.0.0-3, which DAOS does not use
(utils/rpms/fused.sh and package_info.sh set the version).

If you would rather get there through upstream libfuse (#17784), I can redo this PR on top of it:
the backport then is a single patch, which applies to libfuse 3.18.2 and 3.18.3 (the header sync is
already part of 3.18).

A plain update to v1.1.0 was tried before in #16879 and closed after functional test failures.
The PR does not say what failed, and it was based on another work-in-progress branch
(jvolivie/fpm_spdk). With v1.1.0, NLT passes (see Testing). The functional test results of this
PR will show whether an issue remains.

Testing

DAOS master 58d0485 with this PR and #19404, EL9 RPMs and scons install (lab build,
31.10.2026). The validation of the dependency RPMs and the comparison of the fused sources were
done on an earlier base (0dbc4dd) with the same deps/patches/fused and build.config changes.

• Build (EL9, scons prereq builder):
  • fused v1.1.0 is fetched from GitHub and both patches apply with git apply.
  • The resulting fused sources are identical to the fused commit used for the tests of DAOS-19898 dfuse: Add an option to allow idmapped mounts #19404.
  • build_packages.sh --build-range=deps builds fused-devel 1.1.0-1, which has
    FUSE_CAP_ALLOW_IDMAP, and all 31 dependency RPMs pass validation (on 0dbc4dd).
  • dfuse from this build passes test_il_allow_idmap of DAOS-19898 dfuse: Add an option to allow idmapped mounts #19404 on Linux 7.2 and logs that
    idmapped mounts were allowed.
• NLT with this fused and DAOS-19898 dfuse: Add an option to allow idmapped mounts #19404, Linux 7.2: the whole posix suite passes (98 tests), also
  with --allow-idmap forced on every dfuse.
• DAOS functional tests (ftest) that CI runs on VMs for dfuse changes, with this fused and
  DAOS-19898 dfuse: Add an option to allow idmapped mounts #19404. Each test ran twice, with and without --allow-idmap on every dfuse, and gave the same
  result both times.
  • 38 pass. Five tests fail, the same way with and without --allow-idmap:
    test_bashfd_pil4dfs and the libaio fio step of test_bashcmd_pil4dfs* also fail on master
    with fused v1.0.0 (checked on 0dbc4dd), and
    test_bashcmd and test_bashcmd_ioil end with a curl of a host on the CI network, after
    all their file system steps have passed. Details are in DAOS-19898 dfuse: Add an option to allow idmapped mounts #19404.
  • dfuse_test passes in all 4 cache modes without the interception libraries, and in the 3
    modes other than writeback (as in ftest) with them.
• Mounting on a plain EL9.7 client (Linux 5.14 and 7.2, SELinux enforcing) works as before:
  • dfuse started by a regular user, mounting through the system's fusermount3 (fuse3 3.16.2),
    in foreground and in daemon mode;
  • dfuse as a systemd service.
• dfuse --allow-idmap: idmapped mounts work on Linux 7.2 and 6.18, including Kubernetes pods
  with hostUsers: false. Details are in DAOS-19898 dfuse: Add an option to allow idmapped mounts #19404.

Features: dfuse

Steps for the author:

• Commit message follows the guidelines.
• Appropriate Features or Test-tag pragmas were used.
• Appropriate Functional Test Stages were run.
• At least two positive code reviews including at least one code owner from each category referenced in the PR.
• Testing is complete. If necessary, forced-landing label added and a reason added in a comment.

After all prior steps are complete:

• Gatekeeper requested (daos-gatekeeper added as a reviewer).

[github-actions]

Ticket title is 'dfuse: support idmapped mounts for containers in user namespaces'
Status is 'Open'
https://daosio.atlassian.net/browse/DAOS-19898