<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - systemd --user mount targets with -t option fails due to lack of root privileges" href="https://bugs.freedesktop.org/show_bug.cgi?id=73809#c11">Comment # 11</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - systemd --user mount targets with -t option fails due to lack of root privileges" href="https://bugs.freedesktop.org/show_bug.cgi?id=73809">bug 73809</a> from <a class="email" href="mailto:systemd-bugs@chris.oldnest.ca" title="Chris <systemd-bugs@chris.oldnest.ca>"> Chris</a> <pre>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?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>