Bug 186914

Summary: CONFIG_SMB_FS is not set in the kernel configuration
Product: [Fedora] Fedora Reporter: Matteo Corti <matteo>
Component: kernelAssignee: Dave Jones <davej>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 5CC: pfrields, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-11-24 23:06:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Matteo Corti 2006-03-27 14:04:45 UTC
Description of problem:
CONFIG_SMB_FS is not set in the kernel configuration

Version-Release number of selected component (if applicable):
2.6.15-1.2054_FC5

How reproducible:
install the corresponding kernel-devel package

Steps to Reproduce:
1. grep SMB /usr/src/kernels/2.6.15-1.2054_FC5-i686/.config 
  
Actual results:
# CONFIG_SMB_FS is not set

Expected results:
CONFIG_SMB_FS=m

Additional info:
I know that CIFS support is in the kernel but SMB is still needed if for example
a user would like to use the uid and gid options that are ignored with CIFS (see
man mount.cifs). This happens if I want to mount a SMB share on a Unix machine
and map the owner and group to a local user.

Comment 1 Steve French 2006-05-18 20:47:14 UTC
uid and gid options are not ignored.  Here is a note I wrote Dave on the topic:

"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"


Comment 2 Dave Jones 2006-10-17 00:39:43 UTC
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

Comment 3 Dave Jones 2006-11-24 23:06:29 UTC
This bug has been mass-closed along with all other bugs that
have been in NEEDINFO state for several months.

Due to the large volume of inactive bugs in bugzilla, this
is the only method we have of cleaning out stale bug reports
where the reporter has disappeared.

If you can reproduce this bug after installing all the
current updates, please reopen this bug.

If you are not the reporter, you can add a comment requesting
it be reopened, and someone will get to it asap.

Thank you.