[GH-ISSUE #5240] On failing to remount a fuse filesystem, give warning instead of erroring out #2931

New issue

Closed

opened 2026-05-05 09:35:35 -06:00 by gitea-mirror · 0 comments

gitea-mirror commented

2026-05-05 09:35:35 -06:00

Owner

Originally created by @alkim0 on GitHub (Jul 6, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5240

I use sshfs a lot (mounts remote ssh directories locally via FUSE). Sometimes, my connection to the server isn't stable, so it will appear that the filesystem is mounted, but none of the contents are accessible (i.e., fails to fstat anything on the mounted directory). At this point, a large majority of programs sandboxed with firejail will fail to start with:

Error fstat: fs.c:534 fs_remount_simple: Input/output error
Error: proc 407052 cannot sync with peer: unexpected EOF

This will happen even for programs which access do NOT access any of the files mounted by sshfs. I feel like this should not be the case.

To give an example, say I have a sshfs mounted directory /home/me/remote-data with:

sshfs remote-server: /home/me/remote-data

Then, my connection to the server becomes flaky, but I wish to access a local pdf file:

zathura /home/me/docs/file.pdf

Zathura will fail to start with the error mentioned above.

Describe the solution you'd like

As far as I can tell, this happens because firejail will try to create a read-only mirror version of the current filesystems with these remounts, but comes across a filesystem it cannot access, and then errors out.

Ideally, instead of erroring out, I would like it to print a warning, not mount that fuse filesystem, and move on to execute the program.

Describe alternatives you've considered

Obviously, I can unmount the sshfs mounted directory, but doing this every time my remote connection gets flaky and then remounting it becomes very annoying.

In addition, starting the program with ignore noexec ${HOME} and ignore read-only ${HOME} also works (since the mirror won't be recreated), but giving up on these protections for a malfunctioning fuse filesystem seems less than ideal.

Additional context

Although the situation I have described is with sshfs, if there are any fuse filesystems with bugs in the future, this error may be raised. While these are "bugs" on the fuse side, I feel like firejail should be robust enough to not prevent me from performing actions which are completely separate from the erroring fuse filesystem.

I believe similar situations have caused issues #3473, #3280, and #3277. Restarting will often work, since it will unmounts the fuse filesystems, and the errors go away.

Originally created by @alkim0 on GitHub (Jul 6, 2022). Original GitHub issue: https://github.com/netblue30/firejail/issues/5240 ### Is your feature request related to a problem? Please describe. I use sshfs a lot (mounts remote ssh directories locally via FUSE). Sometimes, my connection to the server isn't stable, so it will appear that the filesystem is mounted, but none of the contents are accessible (i.e., fails to fstat anything on the mounted directory). At this point, a large majority of programs sandboxed with firejail will fail to start with: ``` Error fstat: fs.c:534 fs_remount_simple: Input/output error Error: proc 407052 cannot sync with peer: unexpected EOF ``` This will happen even for programs which access do NOT access any of the files mounted by sshfs. I feel like this should not be the case. To give an example, say I have a sshfs mounted directory `/home/me/remote-data` with: ``` sshfs remote-server: /home/me/remote-data ``` Then, my connection to the server becomes flaky, but I wish to access a local pdf file: ``` zathura /home/me/docs/file.pdf ``` Zathura will fail to start with the error mentioned above. ### Describe the solution you'd like As far as I can tell, this happens because firejail will try to create a read-only mirror version of the current filesystems with these remounts, but comes across a filesystem it cannot access, and then errors out. Ideally, instead of erroring out, I would like it to print a warning, not mount that fuse filesystem, and move on to execute the program. ### Describe alternatives you've considered Obviously, I can unmount the sshfs mounted directory, but doing this every time my remote connection gets flaky and then remounting it becomes very annoying. In addition, starting the program with `ignore noexec ${HOME}` and `ignore read-only ${HOME}` also works (since the mirror won't be recreated), but giving up on these protections for a malfunctioning fuse filesystem seems less than ideal. ### Additional context Although the situation I have described is with sshfs, if there are any fuse filesystems with bugs in the future, this error may be raised. While these are "bugs" on the fuse side, I feel like firejail should be robust enough to not prevent me from performing actions which are completely separate from the erroring fuse filesystem. I believe similar situations have caused issues #3473, #3280, and #3277. Restarting will often work, since it will unmounts the fuse filesystems, and the errors go away.