Hi everybody!
I had a problem (now solved) with the UIDs and GIDs assigned to my SMB
filesystem once mounted. I have discovered several things and I wanted
to send my review to the list, maybe you'll find it usefull or maybe you
could add more info.
First of all let's describe the problem: I mount my SMB share (SAMBA
3.0.14a server) on my local filesystem (Linux box), but sometimes I
cannot set which is the UID and GID which is assigned to those files
(using the mount options). "Sometimes" means: "with some Linux
distributions I can and with some Linux distributions I can't". It
seemed to be a kernel bug issue, but I couldn't find exact info, so I
made some tests.
An introduction to available filesystem types:
There are three possible filesystem types which you can use to mount
the share on your linux Box: "smb" , "smbfs" (which I think
that are
maintained by the Linux Kernel Team) and "cifs" (which I think is
maintained by Samba Team). All the tests I've made tell me that
"smb"
amb "smbfs" are synonyms , but "cifs" is different.
"CIFS VFS" allows
you to use the "CIFS Unix extensions".
As you know, the "mount" command allows you to set the options
"uid"
and "gid" which SHOULD BE the uid and gid assigned to your local view
of
the remote files once mounted the share on you local filesystem. There's
an exception:
Excerpt from "man mount.cifs":
"uid=arg
sets the uid that will own all files on the
mounted filesystem. It may be specified
as either a username or a numeric uid.
This parameter is ignored when the target
server supports the CIFS Unix extensions."
So, it's clear that if your SAMBA server supports the "CIFS Unix
extensions" (does it by deafault) then if you use the "cifs"
filesystem
type on your samba client box and your UID is different from the UID
that the Samba server has assigned to you, then you will have problems
accessing to your files.
Then, maybe you think, "well, let's enable the CIFS Unix extension on
my Samba server, so the Samba clients will choose if they want to use
the cifs filesystem to mount their shares". Well ... if you do so you
will probably have problems, because there are some Linux Kernel issues
that will affect you. I have been testing the three mounting filesystem
types within a total of 9 different linux distributions and 15 different
kernels.
I've tested mounting an SMB samba share with the three filesystems
"smb", "smbfs" and "cifs" having the "CIFS
Unix extensions" enabled on
the server, and I've found four different behaviours:
1) Mount ok and UID and GID options on mount respected. Let's call it
"uid_OK".
2) Mount ok and UID and GID are the one's from the Samba server, by the
CIFS Unix Extensions. Let's call it "remote_uid".
3) Mount ok, but UID and GID aren't neither the one's from the mount
options neither the one's from the Samba server. Let's call it
"unknown_uid".
4) Couldn't mount, kernel not supporting the filesystem, probably fixed
applying kernel patches and patience. Let's call it "NoSupport".
With this 2 axis (kernel / mouting case) the results are:
- Ubuntu 5.04 ("Hoary")
kernel GNU/Linux 2.6.10-5-386
lin_1 - smb: uid_OK
lin_1 - smbfs: uid_OK
lin_1 - cifs: remote_uid
- Ubuntu 5.10 ("Breezy")
kernel GNU/Linux 2.6.11-1-686
lin_2 - smb: uid_OK
lin_2 - smbfs: uid_OK
lin_2 - cifs: remote_uid
kernel GNU/Linux 2.6.7-1-686
lin_3 - smb: remote_uid
lin_3 - smbfs: remote_uid
lin_3 - cifs: remote_uid
- Knoppix 3.8 (live system)
kernel GNU/Linux 2.6.11
lin_4 - smb: uid_OK
lin_4 - smbfs: uid_OK
lin_4 - cifs: remote_uid
- Fedora Core 1
kernel GNU/Linux 2.4.22-1.2115.nptl
lin_5 - smb: uid_OK
lin_5 - smbfs: uid_OK
lin_5 - cifs: NoSupport
kernel GNU/Linux 2.4.22-1.2199.nptl
lin_6 - smb: uid_OK
lin_6 - smbfs: uid_OK
lin_6 - cifs: NoSupport
- Fedora Core 2
kernel GNU/Linux 2.6.5-1.358
lin_7 - smb: remote_uid
lin_7 - smbfs: remote_uid
lin_7 - cifs: NoSupport
kernel GNU/Linux 2.6.10-1.771_FC2
lin_8 - smb: uid_OK
lin_8 - smbfs: uid_OK
lin_8 - cifs: remote_uid
- Fedora Core 3
kernel GNU/Linux 2.6.9-1.667
lin_9 - smb: remote_uid
lin_9 - smbfs: remote_uid
lin_9 - cifs: remote_uid
kernel GNU/Linux 2.6.10-1.770
lin_10 - smb: uid_OK
lin_10 - smbfs: uid_OK
lin_10 - cifs: remote_uid
kernel GNU/Linux 2.6.11-1.14
lin_11 - smb: uid_OK
lin_11 - smbfs: uid_OK
lin_11 - cifs: remote_uid
- SuSE Enterprise Linux 9
(ok, haven't tried very much)
kernel GNU/Linux 2.6.5-7.97
lin_12 - smb: NoSupport
lin_12 - smbfs: unknown_uid
lin_12 - cifs: NoSupport
- DEBIAN 3.0
kernel GNU/Linux 2.4.18
lin_13 - smb: uid_OK
lin_13 - smbfs: uid_OK
lin_13 - cifs: NoSupport
- DEBIAN 3.1
kernel GNU/Linux 2.4.30
lin_14 - smb: uid_OK
lin_14 - smbfs: uid_OK
lin_14 - cifs: NoSupport
kernel GNU/Linux 2.6.8
lin_15 - smb: remote_uid
lin_15 - smbfs: remote_uid
lin_15 - cifs: remote_uid
It seems clear that (at least some) 2.6 kernel versions earlier than
2.6.10 have a bug in SMB VFS (not in CIFS VFS) which doesn't let you
stablish the local UID and GID via mount options. It seems that this
kernel bug is someone called "smbfs does not honor uid, gid, file_mode
and dir_mode supplied by user mount" , but I couldn't find more
detailed
info.
Of course, once disabled the "CIFS Unix extensions" on my Samba
server,
all the cases of "remote_uid" turned to "uid_OK". Also
SuSE's "unknown_uid".
More info:
----------
- man mount.cifs
- http://samba.org/ftp/unpacked/cifsvfs/fs/cifs/README
- https://www.redhat.com/archives/fedora-list/2004-December/msg07408.html
CONCLUSION
----------
This is just an experimental conclusion. If you want to mount the
shares of your Samba server on any kind of Linux workstation and you
cannot assert that this will have a "latest 2.4 kernel" or a kernel
later than 2.6.10 , surely you will have to disable the "CIFS Unix
extensions". Of course, that there could be any other solutions ... but
I couldn't find any, if you know some one, please post it. If all the
users of your Linux Workstations do have the same UIDs and GIDs than the
ones assigned on the Samba server, then you won't have any problem.
Remember that one way share the UIDs and GIDs is to authenticate the
Linux Workstations users against the same LDAP server than the server
via PAM Unix.
Well, nothing more, I thought it could be usefull to share this with
others. Congratulations for this great software. Best regards,
--
Angel Galindo Mu?oz
University of Barcelona, Spain
