-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 17 May 2012 14:37:00 +0200 steve <[email protected]> wrote:
> On 05/17/2012 02:34 AM, Jeff Layton wrote: > > On Wed, 16 May 2012 17:30:23 +0200 > > steve<[email protected]> wrote: > > > >> On 05/16/2012 02:56 PM, steve wrote: > >>> Hi > >>> e.g. > >>> mount.cifs //192.168.1.6/reports /mnt -o rw,setuids,nodev,user=steve2 > >>> > >>> Any file created in the share is always owned by steve2 (or the person > >>> who mounted the share). > >>> > >>> According to man cifs(8), the setuids overrides this but doesn't seem > >>> to work for us. We'd like it to be the same behavior as nfs if that's > >>> possible. > >>> > >>> Version 4.0.0alpha21-GIT-46a41d0 with s3fs > >>> > >>> Cheers, > >>> Steve > >>> > >>> > >> CORRECTION: > >> It _looks_ as though it's owned by the person specified as user _when in > >> the share_ but the actual file (the unmounted file) is always owned by > >> root. > >> Steve > > Sadly, permissions enforcement and handling in cifs.ko are badly > > broken by default. > > > > The only way to do this properly is to switch to using multiuser > > mounts. Have a look at the multiuser option in mount.cifs(8) and > > cifscreds(1). > > > > Cheers, > Hi Jeff > Thanks for the confirmation. Strangely, I found by accident that using > the .gvfs smb:// mount in Nautilus does actually create user owned > files. I'm sure that there must be a catch there somewhere though: > AFAIK, the .gvfs stuff uses a libsmbclient fuse-based fs. Apples and oranges here... > kinit Administrator > mount.cifs -o rw,uid=3000008,sec=krb5 //server/share /somewhere > Calling mount.cifs directly isn't recommended. It's a mount helper that's intended to only be called from /bin/mount. > produces uid 3000008 files no matter who accesses the share. Leaving off > the uid= creates files as uid=root. Maybe the .gvfs is doing what you > described on a who-ever-is-logged-in-and-access's-it basis? > That's correct behavior. If you've specified uid= which tells the client to forcibly override all of the uids in the inodes with the value you provided. It can't do that on the server however. All the server sees is a call to create a file that came from the client by "Administrator". That probably doesn't match up to uid 3000008 on the server, which is why you see the mismatch. What you may want to do is to instead use "-o sec=krb5,multiuser", which will make cifs.ko switch to multiuser mode. In that mode, each uid on the client that accesses the mount will do so using their own credentials and (most importantly) the client won't try to enforce permissions locally. It does mean that every user who accesses the mount will need a krb5 ticket however instead of every user sharing the same set of credentials. - -- Jeff Layton <[email protected]> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBAgAGBQJPvhjQAAoJEAAOaEEZVoIVyq4P/j7te66su6d4RkZJ6DOPELae v89mjwfn79ro4JBRnrdj8M2Qo7vO3a4Y/F7x0VhO2mVmU5P8JPmzunCuS/z31G+k 7hHUCTbl1sME2tePHk18SybW/zbrKINPJjK+pzkyoDfWLRZjDF0yeJv2rSFjI2ET tAd71oZ2gyOtPJemZwAkeGrqDIEENS0D5m1U0HNKkOyqd7VJxxvu+C6Z8bD2jYKR ByO63Fe6D7YM+ldGPCR+XLgGj7aBTzeWTdrvzPXWPMEl09btG7Yy6kktlLanae3T a6LZ2p2r66/18OfFgZpR9Mifgd4diZx/bNTKaM59joh1DUyrPOT8o7xs7Pdi2XW6 E+NUCbDoZZ4zo7mfdZDRHYTVDw6Z6LhXE6O+gvpzBvMeDVWx4ciW+64c2ml6GdIv NS1wX74joA7Hwb9Mnnr5mhUUjnZXpviSDFFY6DESEI4okJFY7bxGv6+rllnPrbji GKqW4xhR0Bl9/TzXnKY4yvJMcL94wbuLo+c1TGKcC6Q+ObNEHrcny3LMe+wYb2fo rCwPrZ3essw6J8j6/u42eol0pC4BjWgfMr1ex/HTyHiMycCTKd+rVL2cO94751at spGZ15HZ9hMJZow0S9A41/JG+5enHSz+PX4DfnFAIKd+rpIbqX2N1bkZsyyIup/s Yc32hr1g5iphc5g9hueH =R+2L -----END PGP SIGNATURE----- -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
