Description of problem: I'm trying to mount a cifs filesystem at boot time, but it's not working. The advice found most frequently with Google is to add _netdev to the line in fstab, and the filesystem will be mounted after the network is up. This is not happening. Version-Release number of selected component (if applicable): cifs-util-4.5-2.fc13.i686.rpm How reproducible: Always Steps to Reproduce: 1. put '//someserver/somedir /mnt/somedir cifs _netdev,credentials=/etc/cifspw,rw,mand 0 0' into /etc/fstab 2. put 'username=someuser' and 'password=somepass' into /etc/cifspw 3. reboot Actual results: Filesystem not mounted Expected results: Filesystem mounted Additional info: Log messages: Jun 23 10:45:59 fedora13 kernel: CIFS: Unknown mount option _netdev Jun 23 10:45:59 fedora13 kernel: CIFS: Unknown mount option mand Jun 23 10:45:59 fedora13 kernel: CIFS VFS: Error connecting to socket. Aborting operation Jun 23 10:45:59 fedora13 kernel: CIFS VFS: cifs_mount failed w/return code = -101 Since _netdev is listed as a filesystem independent mount option, you'd expect it to be handled by 'mount', not 'mount.cifs'. I'm also surprised that 'mand' isn't working either, but that's a different bug.
Well, -101 is -ENETUNREACH so it does seem like the mount was attempted before networking was up. As best I can tell though, _netdev is ignored by mount.nfs, so I assume this is what we should do in mount.cifs as well. Reassigning this bug to util-linux for now...
I reassigned this to util-linux as this seems like a /bin/mount problem. Shouldn't /bin/mount be ensuring that networking is up before trying to mount in this case?
Karel, I could use some clarification here. Who is expected to manage the _netdev option? mount.nfs ignores it. mount.cifs passes it to the kernel currently (which we need to fix), but I'd like to know what the expectation with that option actually is. If the mount helpers are expected to handle it, what criteria should be met before allowing the mount to proceed? It really seems like an option that ought to be deprecated -- the situation with networking these days is much more complex than it was when this option was introduced and I'm not sure we can reasonably handle it correctly.
(In reply to comment #2) > I reassigned this to util-linux as this seems like a /bin/mount problem. > Shouldn't /bin/mount be ensuring that networking is up before trying to mount > in this case? Oh.. no. The _netdev option is ignored in mount(8) by default. The options is used by initscripts only. The traditional way how we use this option is to call mount(8) with -O option, man mount: -O Used in conjunction with -a, to limit the set of filesystems to which the -a is applied. Like -t in this regard except that it is useless except in the context of -a. For example, the command: mount -a -O no_netdev I think the best solution is to ignore the option in mount helpers. Really. You don't have to care about it. Now mount(8) calls /sbin/mount.<type> helpers with all fstab & command line options. Maybe we can change this policy. BTW, all MS_COMMENTs from mount(8): { "_netdev", 0, 0, MS_COMMENT}, /* Device requires network */ { "comment", 0, 0, MS_COMMENT}, /* fstab comment only (kudzu,_netdev)*/ { "nofail", 0, 0, M S_COMMENT}, /* Do not fail if ENOENT on dev */
Ok, thanks Karel...moving back to cifs-utils. I've pushed some patches to mainline cifs-utils and to the cifs kernel maintainer for this. Updated cifs-utils fedora packages are forthcoming.
cifs-utils-4.6-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/cifs-utils-4.6-1.fc13
cifs-utils-4.6-1.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update cifs-utils'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/cifs-utils-4.6-1.fc13
cifs-utils-4.6-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.