Unknown FUSE opcode (39)

[vi]

ioctl(TCGETS) on a file opened from a filesystem implemented with fuse-rc causes filesystem to be unmounted:

[2019-12-03T13:26:05Z ERROR fuse::request] Unknown FUSE opcode (39)
[2019-12-03T13:26:05Z INFO  fuse::session] Unmounted /tmp/m

Such ioctl is issued e.g. by git gui on file .git/HEAD for some reason.

Using Linux kernel version 4.19.85.

[mbilker]

I also got this error when doing dd if=<file_in_fuse_mount> skip=<some_offset> of=/dev/null.

[mbilker]

After checking the source code, that opcode is behind a feature flag:

fuse-rs/fuse-abi/src/lib.rs

Lines 275 to 276 in 42e29d9

	#[cfg(feature = "abi-7-11")]
	FUSE_IOCTL = 39,

[zargony]

Interesting. The kernel driver shouldn't send requests with this opcode at all since we're requesting ABI 7.8 in the FUSE_INIT reply.

[mbilker]

I am running Fedora 31 with Linux 5.3.12-300.fc31.x86_64 on the computer with my FUSE server program. According to the upstream Linux kernel source, there is no check against the server's ABI version when sending the IOCTL request [0].

[0] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/fs/fuse/file.c?h=v5.3.12#n2665

[vi]

Can it just safely ignore (ENOSYS) all unknown opcodes with only a warning instead of error?

[ashkitten]

i'm also seeing this issue trying to open files with audacity. it's particularly frustrating that the filesystem immediately unmounts and i can't do anything about it, fuse-rs should handle this more gracefully.

[mbilker]

This looks like it might be easier to implement on the modernize branch. I got around this issue by defining the rest of the opcodes and basic parsing for them, but returns ENOSYS on opcodes that are not implemented.

[delehef]

Hi all,

Until it's implemented in an actually decent fashion, you might use my quick'n dirty fork that I patched for this problem. Basically, it just replies a simple ENOSYS to any unknown request instead of Err-ing.