Review about uid and gid mount option on Linux

Ángel Galindo Muñoz agalindo at
Thu May 26 10:20:23 GMT 2005

	Hi everybody!

	I sent this mail to samba at , but I think it's more 
appropiate to send it to this list. Maybe is usefull for somebody:

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

     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 
sith SMB VFS 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 

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 

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 

	Of course, once disabled the "CIFS Unix extensions" on my Samba server, 
all the cases of "remote_uid" turned to "uid_OK".

	More info:
- man mount.cifs

	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,

Ángel Galindo Muñoz
University of Barcelona, Spain

More information about the smb-clients mailing list