Client & server sides has same version of samba. From manpage SMB.CONF(5): Default: unix extensions = yes Make sure that server side properly configured: # testparm -v -s 2>/dev/null | grep -i 'unix extensions' unix extensions = Yes Some quotation from MOUNT.CIFS(8) about "uid=arg" option: sets the uid that will own all files on the mounted filesystem If the server and client are in the same domain (e.g. running winbind or nss_ldap) and the server supports the Unix Extensions then the uid and gid can be retrieved from the server (and uid and gid would not have to be specifed on the mount For servers which do not support the CIFS Unix extensions, the default uid (and gid) returned on lookup of existing files will be the uid (gid) of the person who executed the mount (root, except when mount.cifs is configured setuid for user mounts) unless the "uid=" (gid) mount option is specified. If I don't supply "uid=arg" option, I see real UIDs (as on server side) [stanv@stanv vid3]$ cifsmount //umka.malta.altlinux.ru/srv share2 --verbose Password: mount.cifs kernel mount options unc=//umka.malta.altlinux.ru\srv,ip=10.2.1.16,user=stanv,pass=q1,ver=1 $ find share2 -printf '%u(%U) %g(%G) %p\n' root(0) root(0) share2 mumu(501) camera(501) share2/for_mumu mumu(501) camera(501) share2/for_mumu/dfadfsdf mumu(501) camera(501) share2/for_mumu/rrr stanv(500) stanv(500) share2/for_stanv stanv(500) stanv(500) share2/for_stanv/sdfsdf stanv(500) stanv(500) share2/for_stanv/bbbbb root(0) root(0) share2/123 т.е. в смонтированом ресурсе мы видим ID владельцев, каковы они являются на сервере. so, on client side i can see real file owners. Now, do the same, but mount using Kerberos authentication. $ kinit Password for stanv@MALTA.ALTLINUX.RU: $ klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: stanv@MALTA.ALTLINUX.RU Valid starting Expires Service principal 03/17/09 15:24:13 03/17/09 22:04:10 krbtgt/MALTA.ALTLINUX.RU@MALTA.ALTLINUX.RU [stanv@stanv vid3]$ cifsmount //umka.malta.altlinux.ru/srv share2 --verbose -osec=krb5,guest parsing options: sec=krb5,guest mount.cifs kernel mount options unc=//umka.malta.altlinux.ru\srv,ip=10.2.1.16,user=stanv,ver=1,sec=krb5,guest,uid=500,gid=500 $ find share2 -printf '%u(%U) %g(%G) %p\n' stanv(500) stanv(500) share2 stanv(500) stanv(500) share2/for_mumu stanv(500) stanv(500) share2/for_mumu/dfadfsdf stanv(500) stanv(500) share2/for_mumu/rrr stanv(500) stanv(500) share2/for_stanv stanv(500) stanv(500) share2/for_stanv/sdfsdf stanv(500) stanv(500) share2/for_stanv/bbbbb stanv(500) stanv(500) share2/123 As wee can see, for all files owner is stanv (500). But, stanv(500) can write/change files in hare2/for_stanv folder. Option "guest" supplied for "Don't ask the password" (with Kerberos auth we don't need password). This all because kernel catch uid=500,gid=500, about wee talk before. CLIENT SYSTEM INFO: $ cat /proc/fs/cifs/LinuxExtensionsEnabled 1 $ /usr/sbin/cifs.upcall -v version: 1.2 $ cifsmount -V mount.cifs version: 1.10-3.0.33 # which cifsmount /usr/bin/cifsmount [root@stanv ~]# rpm -qf /usr/bin/cifsmount samba-client-3.0.33-alt2 [root@stanv ~]# rpm -qi samba-client Name : samba-client Relocations: (not relocatable) Version : 3.0.33 Vendor: ALT Linux Team Release : alt2 Build Date: Thu Mar 5 18:47:58 2009 Install date: Thu Mar 5 18:51:15 2009 Build Host: stanv.malta.altlinux.ru Group : Networking/Other Source RPM: samba-3.0.33-alt2.src.rpm Size : 15304444 License: GNU GPL Packager : Alexander Bokovoy <ab@altlinux.ru> URL : http://www.samba.org/ Summary : Samba (SMB/CIFS) client programs Description : Samba-client provides some SMB clients, which complement the built-in SMB filesystem in Linux. These allow the accessing of SMB shares. Support for printing to SMB printers is in Samba-client-cups package.
Kernel helper cifs.upcall beckported from Samba 3.2
This is a real problem without a nice easy solution that won't break backward compatibility: The problem is that we use the uid= option for two things: 1) to set the ownership of files on a share
Oops, submitted the last comment too fast... The problem is that uid= means too much: 1) it tells the kernel who's credcache it should use to generate the spnego blob 2) it tells the kernel what the default ownership of files should be when unix extensions are disabled 3) when they are enabled, it clobbers the uid's sent by the server So there's currently no way to say "I want to use krb5 creds from an unprivileged user's credcache and I want file ownership information from the server" The right fix is probably to change the behavior so that #3 doesn't happen, and maybe add another mount option that allows someone to get that behavior (forceuid/forcegid or something).
There's now a patch in place in mainline kernels that should fix this. It changes the behavior such that the uid=/gid= options do not override the ownership info provided by the server by default. If you mount with forceuid/forcegid however it enables the legacy behavior. This should be fixed in 2.6.31 when it's released. I'll go ahead and close this bug as FIXED. Please reopen if you find that 2.6.31-rc3 or above doesn't fix it for you.