On failing to remount a fuse filesystem, give warning instead of erroring out

[alkim0]

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.