Bug 50631
| Summary: | CIFS mount fails on kernels after 3.3.8 | ||
|---|---|---|---|
| Product: | File System | Reporter: | Alex Miller (almiller_1) |
| Component: | CIFS | Assignee: | Jeff Layton (jlayton) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | alan, anisse, jlayton, kernel, robink, sprabhu, thomas.jarosch |
| Priority: | P3 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://bugs.gentoo.org/show_bug.cgi?id=442552 | ||
| Kernel Version: | 3.4.5+ | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: | Log of git bisect between 3.3.8 and 3.4.5 | ||
|
Description
Alex Miller
2012-11-16 00:41:41 UTC
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. |