Bug 2203 - using "noauto" for smbfs fails
using "noauto" for smbfs fails
Status: RESOLVED WONTFIX
Product: Samba 3.0
Classification: Unclassified
Component: smbclient
3.0.12
All Linux
: P3 normal
: none
Assigned To: Gerald (Jerry) Carter
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-01 13:18 UTC by Stas Sergeev
Modified: 2005-11-14 09:42 UTC (History)
1 user (show)

See Also:


Attachments
dont pass down "noauto" (383 bytes, patch)
2005-01-01 13:19 UTC, Stas Sergeev
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stas Sergeev 2005-01-01 13:18:08 UTC
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! :)
Comment 1 Stas Sergeev 2005-01-01 13:19:32 UTC
Created attachment 873 [details]
dont pass down "noauto"
Comment 2 Stas Sergeev 2005-01-01 13:39:07 UTC
*** Bug 2202 has been marked as a duplicate of this bug. ***
Comment 3 Iain MacDonnell 2005-01-09 17:20:37 UTC
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
Comment 4 Iain MacDonnell 2005-01-09 17:42:16 UTC
Add "nosuid" and "nodev" to the list too. With all of those added to the
proposed patch, I can mount via fstab OK.
Comment 5 Stas Sergeev 2005-01-09 17:53:13 UTC
> 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.
Comment 6 Stas Sergeev 2005-01-09 17:56:57 UTC
> 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.
Comment 7 Iain MacDonnell 2005-01-09 18:02:57 UTC
Works for me now, but I'm using a slightly dated 2.6.5 kernel (from SuSE SLES9).
Comment 8 Gerald (Jerry) Carter 2005-03-21 19:40:54 UTC
closing trunk for bug filing.  all stable development is going 
on in the Samba 3.0 tree.
Comment 9 Stas Sergeev 2005-03-21 21:26:56 UTC
> 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.
Comment 10 Gerald (Jerry) Carter 2005-03-22 03:43:09 UTC
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.
Comment 11 Stas Sergeev 2005-03-22 10:01:12 UTC
> 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:)
Comment 12 Gerald (Jerry) Carter 2005-03-22 10:41:49 UTC
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).
Comment 13 Stas Sergeev 2005-03-22 11:33:23 UTC
> 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.