Description of problem: See Summary Version-Release number of selected component (if applicable): kernel-2.6.18-128.el5 How reproducible: Always Steps to Reproduce: 1. Mount a DFS share (mount -t cifs -o "user=foobar" <dfs-share> <local>) 2. ls <local> Actual results: Kernel Panic Expected results: List of files and directories within <local>, i.e. on the dfs-share Additional info: Also tried kernel-2.6.18-129.el5.jtltest.60 with the same result. I know this is only a tech preview :)
I think this is probably a known bug. Most likely you're trying to mount the DFS junction point itself. Unfortunately, that currently trips a BUG_ON. If so, the workaround for now is to mount the target of that junction rather than the junction itself. Could you post or attach the oops message here so we can be sure?
Okay, that's what I guesses too, that it's that bug - but I can't tell how the infrastructure is set up, none of my business - I only get the share's adress. How could I get the oops message? It's a real machine not a virtual one or whatever so I figure it's no easy copy-paste.
Ok, getting the oops may be tricky then, let's not worry about that for the moment. Does the share you're mounting have more than one path component? i.e., are you mounting: //servername/share/path/to/directory ...or does it look more like: //servername/share ...if it's more like the former, you may want to try mounting the parent of the dir: //servername/share/path/to ...and then seeing if you can walk into "directory".
//servername/share/path/to/directory -> ls gives kernel panic //servername/share/path/to -> ls gives kernel panic //servername/share/path -> ls gives kernel panic //servername/share -> ls works But when I then cd into a subdir (path/) and do a ls right there, the result's a kernel panic again. When I ls the subdir without cd into it, it says the object is remote.
My test kernels now have Igor's upstream patch that should fix the oops. Could you give it a test when you get a chance? http://people.redhat.com/jlayton/
True, there's no more oops. with 'mount -t cifs ...' I now get "mount error 66 = Object is remote" and with mount.cifs I get: "Mounting the DFS root for domain not implemented yet No ip address specified and hostname not found" A patch to actually enable access to this kind of DFS shares would have been more in my taste, though ;) But no oops is a good start I guess.
Eventually we want to allow that, but it's fairly complicated to mount a DFS share directly. It's going to involve implementing proper caching for DFS referrals (which we don't currently do), being able to re-chase referrals when we have to reconnect, and overhauling the cifs_mount code to handle this properly. So, we're going to have to do this a step at a time. For now, the important thing is to not crash the box when this occurs...
I'm going to go ahead and close this as a duplicate of the bug I have open to update CIFS for 5.4. Unfortunately we probably won't be able to get DFS referral chasing into the mount code for that, but possibly for 5.5 or 5.6. *** This bug has been marked as a duplicate of bug 465143 ***