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:
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
You can file bugs against the cifs fs using the CifsVFS component
For smbfs issues, you are probably better sending mail to the
kernel mailing list (or maybe Urban <email@example.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:
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 <firstname.lastname@example.org> directly
I think Urban is unreachable.