Bug 881481

Summary:	fuse.sshfs with credentials on crypt volume => system cannot boot
Product:	[Fedora] Fedora	Reporter:	Matthew Woehlke <mwoehlke.floss>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	17	CC:	johannbg, lnykryn, metherid, msekleta, notting, plautrba, systemd-maint, vpavlin
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-01-14 21:12:09 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Matthew Woehlke 2012-11-29 00:18:58 UTC

Description of problem:
I have my system set up with an encrypted volume, and an sshfs mount depending on the same, i.e. (simplified):
(/etc/fstab)
/dev/mapper/luks-<UUID> /crypt ext4 defaults 1 2
server:/mount /mount fuse.sshfs idmap=file,uidfile=/crypt/uidmap,gidfile=/crypt/gidmap 0 0
(/root/.ssh/config)
Host server
User user
IdentityFile /crypt/id_rsa

As a result of this configuration, I am unable to boot the machine; systemd insists on trying (and failing) to mount the sshfs file systems before the network is started and before even other mounts (e.g. /home, /var) are up, much less /crypt.

Version-Release number of selected component (if applicable):
systemd-44-21.fc17.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Set up volumes as described.
2. Try to boot computer.

Actual results:
systemd drops into emergency mode and cannot be recovered; only / is mounted (not e.g. /home, /var) and networking is not started. Attempting to start cryptsetup.target or cryptsetup@luks-<UUID>.service sometimes asks for passphrase and sometimes hangs, and tends to self-deactivate. Attempting to start *.mount tends to hang. Attempting to start network fails, kills shell, and goes back into emergency mode. (Basically, it is impossible to boot the system, even with manual coaxing, at this point.)

Expected results:
Asks for crypt volume passphrase; boots successfully, with sshfs files systems mounted.

Additional informatoin:
The most obvious bug seems to be that networking is not being required for sshfs mounts. Figuring out what key ssh wants might be a bit much, although there should also already be a dependency on the crypt volume from the idmap options. (Just having the networking dependency probably is enough that it would work, even if the crypt volume dependency is missing, as networking probably does not start before the local file systems are mounted.)

Possibly related to bug 591836.

Comment 1 Lennart Poettering 2013-01-14 17:30:54 UTC

systemd cannot magically determine that the network needs to be up for a mount. mount uses "_netdev" in the mount options to declare that. If you use that in the mount options this part of the issue should be fixed, as systemd honours that.

Determining the other dependency automatically is not feasible either. We cannot really add support for parsing the options for a gazillion of userspace file systems to systemd to determine the deps. A possible work-around could be to write a .mount unit for this entry and specify the dep explicitly, but that's not particularly sexy.

Comment 2 Matthew Woehlke 2013-01-14 17:39:11 UTC

So, how about adding something similar for other dependencies? The simplest would be e.g. '_dep=crypt.mount' that could depend on anything systemctl knows about; '_netdev' could then be an alias for '_dep=network.target' (guessing that is the equivalent dep, anyway; might be wrong). I think that would be less painful than writing a series of .mount's when more than one FS is affected.

Comment 3 Lennart Poettering 2013-01-14 21:12:09 UTC

That's a good idea I guess!

*** This bug has been marked as a duplicate of bug 812826 ***