Permissions problems are being a huge PIMA

[Reinhold Rumberger]

Am Montag 31 Januar 2011, um 19:39:28 schrieb gene heskett:
> On Monday, January 31, 2011 01:05:15 pm Reinhold Rumberger did opine:

<snip problem description>

> > from man mount.cifs:
> > uid=arg
> >   sets the uid that will own all files or directories on the
> >   mounted filesystem when the server does not provide ownership
> >   information. It may be specified as either a username or a numeric uid.
> >   When not specified, the default is uid 0. The mount.cifs helper must be
> >   at version 1.10 or higher to support specifying the uid in non-numeric
> >   form. See the section on FILE AND DIRECTORY OWNERSHIP AND PERMISSIONS
> >   below for more information.
> > 
> >    forceuid
> >        instructs the client to ignore any uid provided by the server for
> >        files and directories and to always assign the owner to be the
> >        value of the uid= option. See the section on FILE AND DIRECTORY
> >        OWNERSHIP AND PERMISSIONS below for more information.
> 
> My machine didn't have this mount.cifs file,

Depending on the install it might be contained in man mount (search for the 
cifs section).

> so I stole it from another
> defunct install, then following these instructions, I did an umount and a
> remount as root like this:
> 
> mount -t cifs -o
> user=gene,passwd=XXXXXXX,uid=1000,forceuid,gid=1000,forcegid
> //shop.coyote.den/shop-slash /mnt/shop

Assuming (from the path below) that that refers to the root directory on the 
server machine, this is really dangerous as every single directory is now 
writable to your gene user (probably, anyway). Does the method Tom H posted 
not work for you? (I didn't know this was possible in samba):

Am Montag 31 Januar 2011, um 17:51:24 schrieb Tom H:
> If you're using samba, you can use the "username map" smb.conf option
> with /path/to/file/users.map.

> Which did not throw an error, but I still can't save that email to the
> kubuntu box.  Something about a repeating .mbox problem this time.
> copy/paste from the error window:
> 
> Could not write to /mnt/shop/home/gene/emc2/nc_files/gcode/[Emc-users]
> Repeating Code.mbox.part

I don't seem to know this particular error, so you'll have to google it 
yourself... :-P

> I had been using 'security = share' in all my smb.conf files so I changed
> that to 'user' but now I have no permissions to mount it, so back to
> 'share' I guess.
> 
> > Personally, I'd do it via groups, i.e. create a group on all machines
> > that need a common set of permissions with the same GID (say, 1111),
> > add the individual users of each machine to the group and make sure the
> > files/directories you want to share all have read/write permissions set
> > for that group (or for the group field, if cifs doesn't support ACLs -
> > I don't really know cifs).
> 
> Maybe this is something I could fix in the smb.conf file here, and in the
> smb.client file there?

I try to avoid samba where I can, so I don't really know about this.

> That sound a little like a mine field.  But I may have to try it since the
> above didn't appear to work.

If ACLs are supported, it is quite easy and safe. If not, this might lead to 
group hell and could have some *really* annoying side effects.
I'd first try Tom's solution and give serious thought to the changing UID for 
the user (either all to 1000 or to 500, whichever is less work) before I tried 
using groups without ACLs.

> > BTW, the least hacky solution would be to make sure all the users share
> > UID 1000, but that would require that all files belonging to the user
> > which had to be changed are also moved to that UID, and that is quite a
> > hassle.
> 
> That would be more than just a 'hassle' I imagine. ;-)

Well, depends on whether you still know all the paths that would need to be 
adapted. For the home directory it would be as simple as as executing
"chown -R 1000 ~/". Do the same for any ext* or reiserfs partitions that 
contain data the user has access to (multimedia drives come to mind).

It really depends on your setup, for me this would take all of five minutes...

  --Reinhold