* Re: [PATCH 0/7] fix up issues from djwong/fuse4fs-fork
[not found] ` <20260506092858.GC49070@macsyma.local>
@ 2026-05-06 14:34 ` Darrick J. Wong
2026-05-06 15:08 ` Theodore Tso
0 siblings, 1 reply; 3+ messages in thread
From: Darrick J. Wong @ 2026-05-06 14:34 UTC (permalink / raw)
To: Theodore Tso; +Cc: Ext4 Developers List, fuse-devel
[cc fuse-devel]
TLDR for the fuse developers: Ted and I discovered a collision between
the upstream libfuse feature bits and the MacFUSE feature bits, which
causes macfuse to do the wrong thing if you try to enable symlink
pagecache.
https://lore.kernel.org/linux-ext4/20260505225635.GT7765@frogsfrogsfrogs/
On Wed, May 06, 2026 at 11:28:58AM +0200, Theodore Tso wrote:
> On Tue, May 05, 2026 at 03:56:35PM -0700, Darrick J. Wong wrote:
> > FUSE kABI 7.20 added FUSE_AUTO_INVAL_DATA, which is bit 12. It looks to
> > me as though they decided to add their own MacOS-specific feature flags
> > at the end of the u32 want field. Then Linux FUSE added 11 more feature
> > flags, at which point they unthinkingly ported over FUSE_CACHE_SYMLINKS,
> > which collides with FUSE_DARWIN_ACCESS_EXT. Apparently nobody on the
> > macfuse end noticed, so on your machine you're getting whatever
> > "ACCESS_EXT" does.
>
> Yeah....
>
> What MacFuse needs to do is to steal some extra fields from struct
> fuse_init_in and fuse_init_out for the darwin-specific capabilities.
> It turns out it already has conn->{want,capable}_darwin, but there's
> no way to pass it in and out of op_init....
>
> #ifdef __APPLE__
> /*
> * TODO(bf)
> *
> * Resolve conflict with vanilla API. We need a separate field flags for
> * Darwin-only flags. As long as we don't support anything beyond ABI
> * version 7.19 on the kernel-side this should not be an issue, though.
> * We need to clean this up when moving to 7.20 or later.
> */
> if (se->conn.want_darwin & FUSE_DARWIN_CAP_ACCESS_EXT)
> outargflags |= FUSE_DARWIN_ACCESS_EXT;
>
> So I *guess* what MacFuse needs to do is to do something like:
>
> struct fuse_init_in {
> uint32_t major;
> uint32_t minor;
> uint32_t max_readahead;
> uint32_t flags;
> uint32_t flags2;
> uint32_t unused[9];
> uint32_t darwin_flags;
> uint32_t darwin_flags2;
> };
>
> am I right in understanding that fuse_*_{in,out} is private between
> the OS's libfuse and OS's fuse driver or kernel extension, so
> it's not disastrous for fuse_kernel.h for Mac and Linux to drift?
Yeah, the easiest method would be to carve out the darwin_flags field.
If they still want to use flags/flags2, then they could probably still
fix it by redefining whichever feature was added later (probably
FUSE_CACHE_SYMLINKS) because right now they're broken, so it's not an
ABI break to redefine the symbol.
Either way someone will have to talk to the MacFUSE people about this.
> > Does this work?
> >
> > /* MacFUSE overlays feature bits with LinuxFUSE, this is fcked up */
> > #if defined(FUSE_CAP_CACHE_SYMLINKS) && !defined(FUSE_CACHE_SYMLINKS)
> > fuse_set_feature_flag(conn, FUSE_CAP_CACHE_SYMLINKS);
> > #endif
>
> What I'm thinking about doing is adding at the beginning of
> fuse[24]fs.c:
>
> #ifdef __APPLE__
> /*
> * Sigh.... MacFuse is overloading the top bits of the flags field of
> * struct fuse_init_{out} so we have to avoid using these capability
> * flags until this gets fixed in MacFUSE
> */
> #undef FUSE_CACHE_SYMLINKS
> #undef FUSE_NO_OPENDIR_SUPPORT
> #undef FUSE_EXPLICIT_INVAL_DATA
> #undef FUSE_MAP_ALIGNMENT
> #undef FUSE_SUBMOUNTS
> #undef FUSE_HANDLE_KILLPRIV_V2
> #undef FUSE_SETXATTR_EXT
> #undef FUSE_INIT_EXT
> #endif
That works for now. If macfuse fixes themselves, then I guess we could
turn that into a configure check.
--D
>
> - Ted
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 0/7] fix up issues from djwong/fuse4fs-fork
2026-05-06 14:34 ` [PATCH 0/7] fix up issues from djwong/fuse4fs-fork Darrick J. Wong
@ 2026-05-06 15:08 ` Theodore Tso
2026-05-06 16:39 ` Darrick J. Wong
0 siblings, 1 reply; 3+ messages in thread
From: Theodore Tso @ 2026-05-06 15:08 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: Ext4 Developers List, fuse-devel
On Wed, May 06, 2026 at 07:34:13AM -0700, Darrick J. Wong wrote:
> [cc fuse-devel]
>
> TLDR for the fuse developers: Ted and I discovered a collision between
> the upstream libfuse feature bits and the MacFUSE feature bits, which
> causes macfuse to do the wrong thing if you try to enable symlink
> pagecache.
This is the patch for fuse2fs and fuse4fs in e2fsprogs which works
around the problem (tested on MacOS using macfuse 5.2.0_1 from
MacPorts). More details about why it was needed is in the commit
description.
- Ted
From 67f1ec55a1309abead16cad883e38b798a567191 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <tytso@mit.edu>
Date: Wed, 6 May 2026 10:51:56 -0400
Subject: [PATCH] fuse2fs, fuse4fs: Fix MacFuse compatibility issue
Unfortunately, MacFuse is overloading the top bits of the flags field
in struct fuse_init_{out} for MacFuse-specific capability extensions.
This results in an attempt to use FUSE_CAP_CACHE_SYMLINKS when linking
with the libfuse in MacPorts will end up enabling
FUSE_DARWIN_CAP_ACCESS_EXT with MacFuse. Hilarity then ensues with
all non-privileged access failing with permission denied.
The change which is needed in MacFuse is described in a TODO(bf)
statement:
https://github.com/macfuse/library/blob/ddb630db8327a50b6670ef5e4f5e6da82a549e99/lib/fuse_lowlevel.c#L3415
I plan to submit a bug report to MacFuse, but in the mean time, work around
the problem by disabling the overloaded capability flags on MacOS.
Link: https://lore.kernel.org/r/20260505225635.GT7765@frogsfrogsfrogs
Link: https://lore.kernel.org/r/20260506092858.GC49070@macsyma.local
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
---
fuse4fs/fuse4fs.c | 18 ++++++++++++++++++
misc/fuse2fs.c | 18 ++++++++++++++++++
2 files changed, 36 insertions(+)
diff --git a/fuse4fs/fuse4fs.c b/fuse4fs/fuse4fs.c
index 92847326..2739da92 100644
--- a/fuse4fs/fuse4fs.c
+++ b/fuse4fs/fuse4fs.c
@@ -120,6 +120,24 @@
#endif
#endif /* !defined(ENODATA) */
+#ifdef __APPLE__
+/*
+ * Sigh.... MacFuse is overloading the top bits of the flags field in
+ * struct fuse_init_{out} for MacFuse-specific capability extensions.
+ * Avoid using these fuse3 capability flags until this gets fixed in
+ * MacFUSE
+ */
+#undef FUSE_CAP_CACHE_SYMLINKS
+#undef FUSE_CAP_NO_OPENDIR_SUPPORT
+#undef FUSE_CAP_EXPLICIT_INVAL_DATA
+#undef FUSE_CAP_EXPIRE_ONLY
+#undef FUSE_CAP_SETXATTR_EXT
+#undef FUSE_CAP_DIRECT_IO_ALLOW_MMAP
+#undef FUSE_CAP_PASSTHROUGH
+#undef FUSE_CAP_NO_EXPORT_SUPPORT
+#undef FUSE_CAP_OVER_IO_URING
+#endif
+
#define FUSE4FS_ATTR_TIMEOUT (0.0)
static inline uint64_t round_up(uint64_t b, unsigned int align)
diff --git a/misc/fuse2fs.c b/misc/fuse2fs.c
index c46cfc23..0f2a3c35 100644
--- a/misc/fuse2fs.c
+++ b/misc/fuse2fs.c
@@ -116,6 +116,24 @@
#endif
#endif /* !defined(ENODATA) */
+#ifdef __APPLE__
+/*
+ * Sigh.... MacFuse is overloading the top bits of the flags field in
+ * struct fuse_init_{out} for MacFuse-specific capability extensions.
+ * Avoid using these fuse3 capability flags until this gets fixed in
+ * MacFUSE
+ */
+#undef FUSE_CAP_CACHE_SYMLINKS
+#undef FUSE_CAP_NO_OPENDIR_SUPPORT
+#undef FUSE_CAP_EXPLICIT_INVAL_DATA
+#undef FUSE_CAP_EXPIRE_ONLY
+#undef FUSE_CAP_SETXATTR_EXT
+#undef FUSE_CAP_DIRECT_IO_ALLOW_MMAP
+#undef FUSE_CAP_PASSTHROUGH
+#undef FUSE_CAP_NO_EXPORT_SUPPORT
+#undef FUSE_CAP_OVER_IO_URING
+#endif
+
static inline uint64_t round_up(uint64_t b, unsigned int align)
{
unsigned int m;
--
2.50.1 (Apple Git-155)
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH 0/7] fix up issues from djwong/fuse4fs-fork
2026-05-06 15:08 ` Theodore Tso
@ 2026-05-06 16:39 ` Darrick J. Wong
0 siblings, 0 replies; 3+ messages in thread
From: Darrick J. Wong @ 2026-05-06 16:39 UTC (permalink / raw)
To: Theodore Tso; +Cc: Ext4 Developers List, fuse-devel
On Wed, May 06, 2026 at 05:08:33PM +0200, Theodore Tso wrote:
> On Wed, May 06, 2026 at 07:34:13AM -0700, Darrick J. Wong wrote:
> > [cc fuse-devel]
> >
> > TLDR for the fuse developers: Ted and I discovered a collision between
> > the upstream libfuse feature bits and the MacFUSE feature bits, which
> > causes macfuse to do the wrong thing if you try to enable symlink
> > pagecache.
>
> This is the patch for fuse2fs and fuse4fs in e2fsprogs which works
> around the problem (tested on MacOS using macfuse 5.2.0_1 from
> MacPorts). More details about why it was needed is in the commit
> description.
>
> - Ted
>
> From 67f1ec55a1309abead16cad883e38b798a567191 Mon Sep 17 00:00:00 2001
> From: Theodore Ts'o <tytso@mit.edu>
> Date: Wed, 6 May 2026 10:51:56 -0400
> Subject: [PATCH] fuse2fs, fuse4fs: Fix MacFuse compatibility issue
>
> Unfortunately, MacFuse is overloading the top bits of the flags field
> in struct fuse_init_{out} for MacFuse-specific capability extensions.
> This results in an attempt to use FUSE_CAP_CACHE_SYMLINKS when linking
> with the libfuse in MacPorts will end up enabling
> FUSE_DARWIN_CAP_ACCESS_EXT with MacFuse. Hilarity then ensues with
> all non-privileged access failing with permission denied.
>
> The change which is needed in MacFuse is described in a TODO(bf)
> statement:
>
> https://github.com/macfuse/library/blob/ddb630db8327a50b6670ef5e4f5e6da82a549e99/lib/fuse_lowlevel.c#L3415
>
> I plan to submit a bug report to MacFuse, but in the mean time, work around
> the problem by disabling the overloaded capability flags on MacOS.
>
> Link: https://lore.kernel.org/r/20260505225635.GT7765@frogsfrogsfrogs
> Link: https://lore.kernel.org/r/20260506092858.GC49070@macsyma.local
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Looks fine for now...
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
--D
> ---
> fuse4fs/fuse4fs.c | 18 ++++++++++++++++++
> misc/fuse2fs.c | 18 ++++++++++++++++++
> 2 files changed, 36 insertions(+)
>
> diff --git a/fuse4fs/fuse4fs.c b/fuse4fs/fuse4fs.c
> index 92847326..2739da92 100644
> --- a/fuse4fs/fuse4fs.c
> +++ b/fuse4fs/fuse4fs.c
> @@ -120,6 +120,24 @@
> #endif
> #endif /* !defined(ENODATA) */
>
> +#ifdef __APPLE__
> +/*
> + * Sigh.... MacFuse is overloading the top bits of the flags field in
> + * struct fuse_init_{out} for MacFuse-specific capability extensions.
> + * Avoid using these fuse3 capability flags until this gets fixed in
> + * MacFUSE
> + */
> +#undef FUSE_CAP_CACHE_SYMLINKS
> +#undef FUSE_CAP_NO_OPENDIR_SUPPORT
> +#undef FUSE_CAP_EXPLICIT_INVAL_DATA
> +#undef FUSE_CAP_EXPIRE_ONLY
> +#undef FUSE_CAP_SETXATTR_EXT
> +#undef FUSE_CAP_DIRECT_IO_ALLOW_MMAP
> +#undef FUSE_CAP_PASSTHROUGH
> +#undef FUSE_CAP_NO_EXPORT_SUPPORT
> +#undef FUSE_CAP_OVER_IO_URING
> +#endif
> +
> #define FUSE4FS_ATTR_TIMEOUT (0.0)
>
> static inline uint64_t round_up(uint64_t b, unsigned int align)
> diff --git a/misc/fuse2fs.c b/misc/fuse2fs.c
> index c46cfc23..0f2a3c35 100644
> --- a/misc/fuse2fs.c
> +++ b/misc/fuse2fs.c
> @@ -116,6 +116,24 @@
> #endif
> #endif /* !defined(ENODATA) */
>
> +#ifdef __APPLE__
> +/*
> + * Sigh.... MacFuse is overloading the top bits of the flags field in
> + * struct fuse_init_{out} for MacFuse-specific capability extensions.
> + * Avoid using these fuse3 capability flags until this gets fixed in
> + * MacFUSE
> + */
> +#undef FUSE_CAP_CACHE_SYMLINKS
> +#undef FUSE_CAP_NO_OPENDIR_SUPPORT
> +#undef FUSE_CAP_EXPLICIT_INVAL_DATA
> +#undef FUSE_CAP_EXPIRE_ONLY
> +#undef FUSE_CAP_SETXATTR_EXT
> +#undef FUSE_CAP_DIRECT_IO_ALLOW_MMAP
> +#undef FUSE_CAP_PASSTHROUGH
> +#undef FUSE_CAP_NO_EXPORT_SUPPORT
> +#undef FUSE_CAP_OVER_IO_URING
> +#endif
> +
> static inline uint64_t round_up(uint64_t b, unsigned int align)
> {
> unsigned int m;
> --
> 2.50.1 (Apple Git-155)
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-05-06 16:39 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260504233301.2345652-1-tytso@mit.edu>
[not found] ` <20260505000831.GA1101423@frogsfrogsfrogs>
[not found] ` <20260505072144.GC16497@macsyma-wired.lan>
[not found] ` <20260505155821.GI1101423@frogsfrogsfrogs>
[not found] ` <20260505220441.GB49070@macsyma.local>
[not found] ` <20260505225635.GT7765@frogsfrogsfrogs>
[not found] ` <20260506092858.GC49070@macsyma.local>
2026-05-06 14:34 ` [PATCH 0/7] fix up issues from djwong/fuse4fs-fork Darrick J. Wong
2026-05-06 15:08 ` Theodore Tso
2026-05-06 16:39 ` Darrick J. Wong
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox