Permissions problems are being a huge PIMA

gene heskett gheskett at
Mon Jan 31 18:39:28 UTC 2011

On Monday, January 31, 2011 01:05:15 pm Reinhold Rumberger did opine:

> Am Montag 31 Januar 2011, um 16:46:16 schrieb gene heskett:
> > Greetings;
> > 
> > I do the 99.999999999% of my email activities from a nice comfy chair,
> > in a nice comfy heated house.
> > 
> > My pair of Kubuntu installs are in the garage (rarely fired up in
> > colder weather because the car is in the way) and in an outbuilding
> > that is only heated enough to control the dew point and protect the
> > machinery there from rust, as it likewise gets relatively little use
> > when the temps go below about 45F.
> > 
> > The machine in the shop runs 24/7 though, so it is 'mounted' as a cifs
> > share, and this is where the PIMA starts.
> > 
> > Because the *buntu's start their user number schemes at 1000, whereas
> > the rest of the known universe starts at 500, even though I am the
> > user gene on both boxes, I have no write perms via cifs in the
> > /home/gene tree on the milling machines kubuntu install.
> > 
> > So that I can save a useful bit of rs-274 nc code directly from an
> > email received on this machine, directly to the
> > /home/gene/emc/nc_files directory on that *buntu box in the shop,
> > what then is the std procedure to establish that the user gene=500 on
> > this box, is the user gene=1000 on that box?
> 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
> 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, 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 
//shop.coyote.den/shop-slash /mnt/shop

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 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?

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

> 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. ;-)
Thanks Reinhold.

Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
You can now buy more gates with less specifications than at any other time
in history.
		-- Kenneth Parker

More information about the kubuntu-users mailing list