Bug 50631 - CIFS mount fails on kernels after 3.3.8
Summary: CIFS mount fails on kernels after 3.3.8
Status: CLOSED CODE_FIX
Alias: None
Product: File System
Classification: Unclassified
Component: CIFS (show other bugs)
Hardware: All Linux
: P3 normal
Assignee: Jeff Layton
URL: https://bugs.gentoo.org/show_bug.cgi?...
Keywords:
: 49401 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-11-16 00:41 UTC by Alex Miller
Modified: 2013-11-19 18:41 UTC (History)
7 users (show)

See Also:
Kernel Version: 3.4.5+
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
Log of git bisect between 3.3.8 and 3.4.5 (3.54 KB, text/x-log)
2012-11-16 00:41 UTC, Alex Miller
Details

Description Alex Miller 2012-11-16 00:41:41 UTC
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
Comment 1 Tom Wijsman 2012-11-16 01:33:55 UTC
Downstream bug at https://bugs.gentoo.org/show_bug.cgi?id=442552
Comment 2 Sachin Prabhu 2012-11-16 09:24:06 UTC
This regression was introduced by the changes to the cifs_parse_mount_options() and is fixed by commit

e73f843a3235a19de38359c91586e9eadef12238
Comment 3 Jeff Layton 2012-11-16 10:28:27 UTC
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...
Comment 4 Tom Wijsman 2012-11-16 16:38:16 UTC
> 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.
Comment 5 Jeff Layton 2012-11-16 17:42:47 UTC
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
Comment 6 Jeff Layton 2012-11-16 17:44:14 UTC
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.
Comment 7 Jeff Layton 2012-11-17 15:54:19 UTC
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.
Comment 8 Alex Miller 2012-11-19 14:12:10 UTC
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.
Comment 9 Anisse Astier 2013-02-25 10:27:49 UTC
*** Bug 49401 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.