I don't think there's much we can do here. systemd user instances don't run as root. I guess it would be up to /bin/mount to relax its rules and allow -t for unprivileged callers in some cases.

I'm really not sure if I want to play with this and open Pandora's box. It's fine to call 

 mount /path

and have all necessary properties in /etc/fstab.

If systemd user instances don't run as root then why does it call root-only commands (like mount -t)? IMHO you can improve systemd to use "mount /path" and assume usable fstab setting if executed as non-root.

Karel, I think my point is that systemd allows you to create userspace mount targets,

However, they don't really work, since systemd is calling mount -t which is root only. Maybe there could be an option to use fusermount which IIRC works under non-root accounts?

I should probably let you know that we abandoned this project, so I don't really need this anymore.

If you decide that this is the best it gets, feel free to close this BZ.

OK, maybe we should think about calling fusermount directly.

Hi,

Any update on this issue? I've got a similar use case that requires mount options to be passed but, at the same time, I don't need systemd to use 'mount', rather, I need it to use sshfs (or fusermount) so the operation can be performed with user permissions:

systemctl --user start home-administrator-Calibre\\x2dssh.mount

май 01 18:19:00 UX32LN systemd[3196]: Reloading.
май 01 18:19:16 UX32LN systemd[3196]: home-administrator-Calibre\x2dssh.mount: Directory /home/administrator/Calibre-ssh to mount over is not empty, mounting anyway.
май 01 18:19:16 UX32LN systemd[3196]: Mounting Mount calibre library directory via sshfs...
май 01 18:19:16 UX32LN mount[11031]: mount: only root can use "--options" option
май 01 18:19:16 UX32LN systemd[3196]: home-administrator-Calibre\x2dssh.mount: Mount process exited, code=exited status=1
май 01 18:19:16 UX32LN systemd[3196]: Failed to mount Mount calibre library directory via sshfs.
май 01 18:19:16 UX32LN systemd[3196]: home-administrator-Calibre\x2dssh.mount: Unit entered failed state.

home-administrator-Calibre\x2dssh.mount:

[Unit]
Description=Mount calibre library directory via sshfs

[Mount]
What=<my_server>:<my_path>
Where=/home/administrator/Calibre-ssh
Type=fuse.sshfs
Options=reconnect,nonempty,_netdev,noauto,nofail,delay_connect,IdentityFile=<id_path>,user
TimeoutSec=10

[Install]
WantedBy=default.target

Thanks,
D.

I think systemd could mount at least FUSE filesystems as user by running the FUSE program directly. This would mean translating

[Mount]
What=$what
Where=$where
Type=fuse.$fusetype
Options=$options

to

$fusetype $what $where -o $options

As a bonus, since some FUSE file systems don’t need a source, it would be convenient if What were made optional, translating

[Mount]
Where=$where
Type=fuse.$fusetype
Options=$options

to

$fusetype $where -o $options

(Alternatively, you could run mount.fuse $fusetype#$what $where -o $options, but that doesn’t seem to do much more than adding two default options (dev,suid) and then running the FUSE program normally.)

Please call fusermount instead. It's totally fine if there's a manual flag in [Mount]/fstab-options to make this happen. This is needed to make systemd viable for useful user environments.

(In reply to rektide from comment #7)
> Please call fusermount instead. It's totally fine if there's a manual flag
> in [Mount]/fstab-options to make this happen. This is needed to make systemd
> viable for useful user environments.

Pardon, mount.fuse.

Welp that doesn't appear to work either. Something has to be done to make this ticket viable, to make userland systemd not heinously pathetically crippled & weak.

Perhaps anything detected as /usr/bin/fuse{,23}.[type] could be interpreted as needing to be directly called rather than mount? This is how fuse 2 & fuse 3 apps are differentiating themselves, according to sshfs[1].

[1] https://github.com/libfuse/sshfs/issues/92#issuecomment-328450030

(In reply to rektide from comment #9)
> Perhaps anything detected as /usr/bin/fuse{,23}.[type] could be interpreted
> as needing to be directly called rather than mount? This is how fuse 2 &
> fuse 3 apps are differentiating themselves, according to sshfs[1].
> 
> [1] https://github.com/libfuse/sshfs/issues/92#issuecomment-328450030

Looking further at the work sshfs committed, there's a commit where they create /usr/bin/mount.fuse.sshfs. Detecting if type matches this last componenet ought to be sufficient for detecting the need to divert from use of mount & to a fuse alternative.

Is there any interest in getting this fixed?

I'm in the same situation as others here, in that I have use-cases in which user units automounting sshfs via FUSE would be extremely helpful. For example: family members with separate accounts on a Linux fileserver can all have their own collections of music, movies, etc. 
* Log in to the server as Alice and you have read/write access to Alice's library and read-only access to Bob's and Carol's. Cool.
* Alice's single-user client machine can use a systemd 'system' mount/automount pair to log in (using a root-owned ssh key on the client) as Alice, and get the same result. So far, so good.
* On a shared laptop, Alice can manually mount the shared media library using her own ssh key and get the expected access. So can Bob and Carol. Yay FUSE!  
A systemd 'system' unit breaks here, because it can only offer one ssh key unless you employ some truly hideous hacks to either rewrite the unit file or rename an ssh key to 'current' or similar whenever a user logs into an X session, or something. (I don't know whether templating could theoretically help with this, but it doesn't matter because you can't template a .mount unit anyway.)
* If systemd were smart enough to see the "Type=fuse.sshfs" and actually use FUSE to mount it (at *least* when it's a user instance), we would easily be able to deploy 'user' mount and automount units that use the %h and %u specifiers to use Alice's ssh key to connect to alice@server and mount the library (with correct permissions) to a mountpoint in /home/alice/ when running in Alice's user systemd instance.

But no, currently the options are either a crude "1 client machine == 1 'user' on the server" mapping via systemd-managed mounts, or if you want proper access control you bypass systemd and put the sshfs command in a desktop autostart entry or something.

As a workaround, I suppose I might try building a user .service unit to Exec the sshfs command and make it PostExec the unmount command at user logout and explicitly define the dependencies that a .mount unit has implicitly... That might possibly work, but it sure would be nice if user-level .mount units would properly handle user-level mount actions instead of rigidly using a root-only mount command that's guaranteed to fail. And given that FUSE exists specifically to solve the problem of letting users mount filesystems, having user .mount units recognize FUSE "Type=" entries and mount them using FUSE just seems like the right thing to do... doesn't it?