Not sure how to debug this, but systemd automounting seems not to be working reliably in recent F17. On some boots it works, but on most it doesn't. Easy enough to illustrate: [adamw@adam systemd (master)]$ grep data /etc/fstab //192.168.1.13/Volume_1 /share/data cifs rsize=8192,wsize=8192,nosuid,soft,user=guest,noauto,iocharset=utf8,mapchars,comment=systemd.automount 0 0 [adamw@adam systemd (master)]$ ls /share/data [adamw@adam systemd (master)]$ su Password: [root@adam systemd (master)]# mount /share/data Password: l[root@adam systemd (master)]# ls /share/data audio ffp misc_images pictures Sales Resume.doc backups ffp.log Nas_Prog repo sammy_wallpaper correspondence fun_plug nmj_database roms video [root@adam systemd (master)]# rpm -q systemd systemd-44-1.fc17.x86_64 (at the 'Password:' prompt I just hit enter, the share doesn't actually need a password). This used to work fine; some time in the last couple of weeks it's stopped working on most boots. How can I debug this? Thanks!
Does https://bugzilla.redhat.com/show_bug.cgi?id=787314#c9 help?
Sorry for the extremely delayed response, but no, it doesn't. That seems to be in current NM in F17: [adamw@adam ~]$ ls /lib/systemd/system/remote-fs-pre.target.wants/NetworkManager-wait-online.service /lib/systemd/system/remote-fs-pre.target.wants/NetworkManager-wait-online.service [adamw@adam ~]$ rpm -qf /lib/systemd/system/remote-fs-pre.target.wants/NetworkManager-wait-online.service NetworkManager-0.9.4.0-9.git20120521.fc17.x86_64 (so that bug should probably be closed now), but: [adamw@adam ~]$ ls /share/data/ [adamw@adam ~]$ (note the conspicuous lack of automounting). It's just broken. Has been this whole time.
Is this bug specific to cifs mounts? Can you try an automount of anything else?
No, and I already did: ircproxy:/ /home/adamw/irclogs nfs noauto,comment=systemd.automount0 0 [adamw@adam ~]$ ls /home/adamw/irclogs/ [adamw@adam ~]$ Both these used to work.
the lack of a space between systemd.automount and 0 0 is a paste artifact, there's really a tab between them.
This is still broken for me in F18. Let's look at one mount: //192.168.1.13/Volume_1 /share/data cifs rsize=8192,wsize=8192,nosuid,soft,user=guest,guest,noauto,iocharset=utf8,mapchars,comment=systemd.automount 0 0 systemd-fstab-generator seems to run on it. I have /run/systemd/generator/share-data.mount and /run/systemd/generator/share-data.automount files. content: share-data.mount ---------------- # Automatically generated by systemd-fstab-generator [Unit] SourcePath=/etc/fstab DefaultDependencies=no After=remote-fs-pre.target Wants=remote-fs-pre.target Conflicts=umount.target Before=umount.target [Mount] What=//192.168.1.13/Volume_1 Where=/share/data Type=cifs FsckPassNo=0 Options=rsize=8192,wsize=8192,nosuid,soft,user=guest,guest,noauto,iocharset=utf8,mapchars,comment=systemd.automount share-data.automount -------------------- # Automatically generated by systemd-fstab-generator [Unit] SourcePath=/etc/fstab DefaultDependencies=no Conflicts=umount.target Before=umount.target remote-fs.target [Automount] Where=/share/data So that much is working. 'systemctl status share-data.mount' and 'systemctl status share-data.automount' give what looks like sane output: [root@adam irclogs]# systemctl status share-data.mount share-data.mount - /share/data Loaded: loaded (/etc/fstab) Active: inactive (dead) Where: /share/data What: //192.168.1.13/Volume_1 CGroup: name=systemd:/system/share-data.mount [root@adam irclogs]# systemctl status share-data.automount share-data.automount Loaded: loaded (/etc/fstab) Active: inactive (dead) Where: /share/data But if I do 'ls /share/data': [root@adam irclogs]# ls /share/data/ [root@adam irclogs]# nothing, at all. No error message. Nothing in /var/log/messages or journalctl. Not sure what else to look at now.
'systemctl start share-data.mount' seems to bring up the mount fine.
Could you retest and confirm if you are you still experiencing this with latest systemd release in F17/F18/F19? Thanks
Oh hey, I forgot I filed a bug on this. I actually came back to this yesterday and finally figured it out: all it needed was a 'systemctl enable remote-fs.target'. I have no idea how it ever got disabled, but that was all it needed.