when mounting fails while using setuid=user,drop_privileges, the mountpoint ends up in an unusable state

[calestyo]

Hey.

When mounting a filesystem via e.g.:

# /usr/sbin/mount.fuse3 user@host:/ /mnt -w -t fuse.sshfs -o nouser,nodev,noexec,nosuid,noatime,default_permissions,auto_unmount,setuid=someuser,drop_privileges,reconnect,idmap=user,disable_hardlink,IdentityFile=/etc/foo/ssh/id_ed25519,ServerAliveInterval=4,ServerAliveCountMax=2,ConnectTimeout=8,ControlPath=none
read: Connection reset by peer

fails (in the above a example because /etc/foo/ssh wasn't readabe by someuser), the mount point remains in a state like:

d????????? ? ?    ?      ?            ? /mnt

which does not happen if drop_privileges is not used.
It dos not show up in /proc/mounts but does so in /proc/self/mountinfo as `someuser´.

Repeating the mount, even when the permission problem has been solved, while it's still in that ???? state, causes:

fuse: failed to access mountpoint /mnt: Transport endpoint is not connected

Only way to clean that up is to call an umount on the mountpoint.

Would be nice if the failed mount could be cleaned up, even if drop_privileges, which is important if one e.g. wants to use setuid=user but on a dir that is not owned by user, with the background, that some process should not be able to write into that location, when it's not mounted (in order to catch that error).

Thanks, Chris.