sshfs option idmap=file causes sshfs to not mount anything at all

[Jan Smith]

While this option is documented, using it makes the command exit with code 1 and not mount anything at all. Doing research about this showed that the whole sshfs project looks abandoned and unmaintained. Given that this package is an important part of Linux, it is worrying that the source code has been archived on GitHub and there seems to be nobody to support this very important Linux functionality.

Steps to reproduce:

* make sure sshd is installed and running
* create two subdirectories somewhere, e.g. "server", "client"
* create the two files: uidfile, gidfile
* files can be left empty or get filled e.g. with yourusername:youruserid, yourgroupname:yourgroupid
* try mounting the server directory at the client mountpoint:
  sshfs -d localhost:/PATHTHO/server /PATHTO/client -o idmap=file,uidfile=uidfile,gidfile=gidfile
* (the -d options prevents the command from spawning the mount process in the background and should normally stay active
  until terminated, but because of the bug, the command exits and does not mount anything)

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: sshfs 3.7.1+repack-2
ProcVersionSignature: Ubuntu 5.19.0-32.33~22.04.1-generic 5.19.17
Uname: Linux 5.19.0-32-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu82.3
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: MATE
Date: Tue Feb 21 08:46:04 2023
InstallationDate: Installed on 2022-05-30 (266 days ago)
InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1)
SourcePackage: sshfs-fuse
UpgradeStatus: Upgraded to jammy on 2022-09-22 (151 days ago)

[Jan Smith (johsmi9933)]

Details: https://github.com/deadbeefsociety/sshfs/issues/6

The problem is that sshfs just exits with error code 1 and NO MESSAGE AT ALL when any problem is encountered with any of the settings in either the uidfile or the gidfile, which makes it very hard to identify and fix whatever the problem might be.

This happens only if the option nomap is not specified or if it nomap=error, it does not happen if nomap=ignore, however the way the mount then works may be different from what is expected with correctly functioning mappings.