User: Password:
Subscribe / Log in / New account

Re: + deprecate-smbfs-in-favour-of-cifs.patch added to -mm tree

From:  Dave Jones <>
Subject:  Re: + deprecate-smbfs-in-favour-of-cifs.patch added to -mm tree
Date:  Thu, 11 May 2006 13:51:43 -0400
Archive-link:  Article, Thread

On Thu, May 11, 2006 at 12:15:10AM -0700, Andrew Morton wrote:
 > The patch titled
 >      deprecate smbfs in favour of cifs
 > has been added to the -mm tree.  Its filename is
 >      deprecate-smbfs-in-favour-of-cifs.patch
 > See to find
 > out what to do about this
 > From: Andrew Morton <>
 > smbfs is a bit buggy and has no maintainer.  Change it to shout at the user on
 > the first five mount attempts - tell them to switch to CIFS.
 > Come November we'll mark it BROKEN and see what happens.

For Fedora Core 5, I disabled SMBFS for pretty much the same reasons.
Users migrating to CIFS haven't really had any problems so far, except for
this case:
(Which has also come up a few times on Fedora mailing lists since).

I mailed Steve about this, and he did reply, but I can't seem to find it
right now



(Log in to post comments)

Re: + deprecate-smbfs-in-favour-of-cifs.patch added to -mm tree

Posted May 18, 2006 21:00 UTC (Thu) by stevef (guest, #7712) [Link]

The uid issue mentioned was probably not a problem - cifs supports it on mount. Note that the Windows95 and OS/2 backlevel support is pretty close (lanman auth works) although not quite ready for mm yet.

Here was the note I had sent Dave which gives more detail on cifs handling of uids:

I am not aware of a problem with uid/gid mount options, there is more detail in fs/cifs/README in the section on "CIFS VFS Mount Options" under uid/gid but let me know if you see something missing there. I wonder if this is something related to an older mount.cifs only accepting numeric uids?

Basically if the server (e.g. Windows or NetApp or EMC) does not support the CIFS Unix Extensions (an optional protocol extension which Samba, HP and a few other server support) then the default uid and gid for all files/directories on the mount can be set by passing
uid=<name or number>
similarly for gid. The support for handling uid (or gid) as a username (instead of the uid number itself) has been in mount.cifs.c for quite a while, but probably less than a year.

If the server (like Samba) does support Unix extensions, the uids/gids will be reported as whatever the server says - if that behavior is not desired, the user should turn off the Unix Extensions on the client (or server)
e.g. "echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled"

I don't mind extending this (default uid/gid behavior) to add more features if you see something obvious (differences in defaults for directories/files etc.). I have been thinking that both NFSv4 and CIFS need a way to remap uids on the client in a more flexible way (as some nfs v3 servers used to allow) - to allow for cases where the server and client uids do not match (and where one default uid for the whole mount is not good enough).

I wish we could disable smbfs faster as well (I get a few questions a month on it) but the two obstacles that I see most often are:

1) Lack of Kerberos (and ntlmv2) support in cifs. As cifs does not (yet) use an upcall to samba for "extended security" flavors of session setup (as smbfs does, albeit in an awkward way) Kerberos support is still most likely a few months away, although ntlvm2 support (which although less well known is good enough for certain government and enterprise security requirements) is missing very little code and could be finished sooner. Part of the obstacle to the cifs upcall for kerberos (and dfs support too) has been the lack of an example for the new cn.ko (connector up call) which would be reusable - as the Samba code that I need to invoke is essentially done
2) Very backlevel server support (mainly allowing very weak lanman passwords, os/2 and windows 95 session setup, and support for mapping Linux time to/from 2 second dos time). I am about halfway through the backlevel sessionsetup (lanman style) support - for obvious security reasons this support would have to be explicitly turned on in /proc/fs/cifs or as mount parm (to allow weak passwords to flow on the wire) and probably be turned off in some menuconfig as well so users don't attempt to mount with weak passwords unless they know what they are doing

Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds