Hi. When I am trying to mount the samba shares that have the "noauto" option in /etc/fstab, I am getting this: --- smbfs: Unrecognized mount option noauto --- The error message itself is not as much of a problem as the fact that all the other mount options gets ignored as soon as the unrecognized one is there. While sounds as a minor issue, this makes the smbfs almost useless for me (without the "codepage" option I can't use it in practice, for example). I have googled and apparently many people had the same problem for ages, and noone have found the solution as of yet, it seems. I think that smbmount have to recognize the "noauto" option (and ignore it) for compatibility. The attached patch does this and the problem goes away. PS: happy new year! :)
Created attachment 873 [details] dont pass down "noauto"
*** Bug 2202 has been marked as a duplicate of this bug. ***
I think this may need to be applied to the "noexec" and "user" options also, as both seem to cause similar problems, but are applicable in /etc/fstab
Add "nosuid" and "nodev" to the list too. With all of those added to the proposed patch, I can mount via fstab OK.
> I think this may need to be applied to the "noexec" and "user" options also I was thinking about that but... "user" implies "noexec", "nosuid" and "nodev". Which in turn will require to also add "exec", "suid" and "dev". And probably many more, resulting in a handfull of mess. My patch was just the minimal change needed to get things working asap. I don't know how will the real fix look like, if it will ever be created. Perhaps mount itself should revoke the parameters that it have handled? But smbfs doesn't work under Linux nowadays anyway, so smbmount is not a big deal. I tried various places to get at least smbfs working, like this: http://bugme.osdl.org/show_bug.cgi?id=3979 but all in vain so far :( I had somewhat better luck with cifs_vfs fortunately.
> Add "nosuid" and "nodev" to the list too. Collision in comments:) Yes, I tried those either, but this is probably still not sufficient, so I stopped at the minimal change.
Works for me now, but I'm using a slightly dated 2.6.5 kernel (from SuSE SLES9).
closing trunk for bug filing. all stable development is going on in the Samba 3.0 tree.
> closing trunk for bug filing. all stable development is going > on in the Samba 3.0 tree. Changing the component to "Samba 3.0" then. This bug was there for *ages* and affected many people. Closing it only because it was filled not against Samba 3.0, probably makes no sense.
we don't maintain smbfs. You'll have to talk to the smbfs kernel module maintainers. Of you can try the cifs fs which is under active development (http://linux-cifs.samba.org/). Wish I had better news for you.
> we don't maintain smbfs. Hmm. But the bug is about smbmount, and the patches too. Who maintains smbmount? I thought the Samba Team does. > Of you can try the cifs fs which > is under active development I am using cifs too, it has much less problems than smbfs, that's for sure. But sometimes one still wants to use smbfs - that's when the Samba server is not 3.x, and so there is no unicode. With that and cifs I wasn't able to get the national chars to display properly, and that's where's the smbfs can help. > Wish I had better news for you. Well, that's kinda strange. If you can tell me where to fill the bug reports about smbmount then, that would be already a sufficient news:)
It's all a little confusing. We definitely don't maintain the smbfs kernel code. The user space mount utilities are in our code tree but I only take patches from Urban Widmark (with a few exceptions). You can file bugs against the cifs fs using the CifsVFS component of https://bugzilla.samba.org/ For smbfs issues, you are probably better sending mail to the kernel mailing list (or maybe Urban <urban@teststation.com> directly).
> The user space mount utilities are in our > code tree but I only take patches from Urban Widmark But thats a bit strange, esp. in the current situation. The patches are trivial, they are only to skip the options that smbfs doesn't recognize. And I am not asking you to apply them as-is, I mainly only wanted to clearly demonstrate where the problem is, in a hope you can fix it one way or another. Someone is trying to fix that bug on an smbfs part: http://www.uwsg.iu.edu/hypermail/linux/kernel/0503.1/2306.html but I think it is more of a mount/smbmount problem, rather than of smbfs. The bug is trivial, either fix will do after all. The worst thing if neither is applied. I thought making the Samba Team aware of the problem would be sufficient to get it fixed, as it is so obvious and simple. So why don't you just look into the patch? :) > or maybe Urban <urban@teststation.com> directly I think Urban is unreachable.