Created attachment 86481 [details] Log of git bisect between 3.3.8 and 3.4.5 Mounting a CIFS file share fails with kernels >3.3.8. The following messages are logged to dmesg: CIFS VFS: Connecting to DFS root not implemented yet CIFS VFS: cifs_mount failed w/return code = -22 Reproducible: Always Steps to Reproduce: 1.Boot with a kernel >3.38 2.Attempt to mount a CIFS file share using a command similar to: mount -t cifs //192.168.0.1/alex /mnt/server -o user=alex,password=(*edited*) Actual Results: mount: wrong fs type, bad option, bad superblock on //192.168.0.1/alex, missing codepage or helper program, or other error (for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program) In some cases useful info is found in syslog - try dmesg | tail or so The following is logged to dmesg: CIFS VFS: Connecting to DFS root not implemented yet CIFS VFS: cifs_mount failed w/return code = -22 Expected Results: The file share mounts successfully. A git bisect between 3.3.8 and 3.4.5 points to this patch as being responsible: 8830d7e07a5e38bc47650a7554b7c1cfd49902bf is the first bad commit commit 8830d7e07a5e38bc47650a7554b7c1cfd49902bf Author: Sachin Prabhu <sprabhu@redhat.com> Date: Fri Mar 23 14:40:56 2012 -0400 cifs: use standard token parser for mount options Use the standard token parser instead of the long if condition to parse cifs mount options. This was first proposed by Scott Lovenberg http://lists.samba.org/archive/linux-cifs-client/2010-May/006079.html
Downstream bug at https://bugs.gentoo.org/show_bug.cgi?id=442552
This regression was introduced by the changes to the cifs_parse_mount_options() and is fixed by commit e73f843a3235a19de38359c91586e9eadef12238
I don't think that'll fix it... The new parser made the unc= option mandatory. That's not a problem when there's a mount helper that provides it, but when there isn't one then most people don't know that they need to add that by hand. The old option parsing code would infer the unc from the device string if a unc= option wasn't present. Note too that this touches on the discussion around the patch that Federico Sauter sent to the linux-cifs mailing list last week: http://article.gmane.org/gmane.linux.kernel.cifs/7328 Here's what I think we ought to do going forward: 1/ have cifs_parse_mount_options parse the devicename into components (host, share, and prefixpath) before parsing any options. Those should be stored in the smb_vol struct for the mount. 2/ when a unc= option is passed in, parse it into components (host and share) and compare its contents to the components parsed from the device string. If there is a difference, use the contents of the unc= option for now, but throw a warning about it and mention unc= will be ignored starting in 3.10. 3/ do the same for prefixpath= option though there should be no need to parse it into components, just compare the two. Use the one passed in the prefixpath= option for now, but warn if there's a difference. 4/ Then, in 3.10 we'll just get rid of the parsing for those options and have them be Opt_ignore. While we're at it, we can get rid of some nasty string parsing in several places. I'll see if I can come up with a patchset for this in time for 3.8. Once we have a fix for mainline, we can assess what to do for stable...
> e73f843a3235a19de38359c91586e9eadef12238 This commit does not fix it because he reported downstream that he is on 3.5.7 and also 3.6.6 on another computer; so, if that were supposed to be a fix for this then it didn't work out, at least not in this case.
Yep, that patch won't fix it. I've just sent a patchset to the cifs maintainer and the linux-cifs mailing list though that should: http://article.gmane.org/gmane.linux.kernel.cifs/7362 ...this should take care of several potential problems in this code and also set us up to deprecate a couple of mount options that really just need to go away. Note that this problem is only an issue if you don't have /sbin/mount.cifs installed. If you install that, it'll provide the mount options the kernel expects and you won't have the problem. Alternately, you can provide a unc= mount option to the kernel as a workaround. From Alex's original problem report, I'd expect something like this to work: # mount -t cifs //192.168.0.1/alex /mnt/server -o username=alex,unc=\\\\192.168.0.1\\alex,password=foobarbaz
Given that there's a simple workaround, I'm going to lower the importance of this problem as well. I'm hoping we can get this patchset merged for 3.8.
Also, if anyone having this problem could help test this patchset, please do and report back whether it helps and whether there were any problems with it.
I have tested Jeff's patches and everything is working for me using the command in my initial comment. For reference I used the patches against linux-stable git master from today.
*** Bug 49401 has been marked as a duplicate of this bug. ***