search

zargony / fuse-rs

Rust library for filesystems in userspace (FUSE)
MIT License
1.05k stars 131 forks source link

Unknown FUSE opcode (39) #142

Open vi opened 4 years ago

vi commented 4 years ago

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 commented 4 years ago

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

mbilker commented 4 years ago

After checking the source code, that opcode is behind a feature flag: https://github.com/zargony/fuse-rs/blob/42e29d964e2b24e32e21b179b77e4d0d0a0857ac/fuse-abi/src/lib.rs#L275-L276

zargony commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

ashkitten commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.