Samba and file permissions

[HughShane]

Suse 9, Samba 3 and a dozen WinXP Pro users. Users saving M$ Word documents to a common area (/common/docs/) find that other users' documents are read-only. I've played around with force create mode and force directory mode (both currently set to 0775) in smb.conf until I'm blue in the face but I cannot get to the situation where a document saved by one user can be edited and saved by another. All users are in one group called 'feet'. Tearing my hair out over this 'simple' little thing! Can anyone point me in the right direction please?

 

[smah]

Odds are, that the filesystem permissions are the problem. The filesystem permissions override anything you might set within Samba.

chgrp -R feet /common/docs
chmod -R 755 /common/docs
(or whatever's appropriate)

 

[smah]

Oops.... that should have been 775
Also have a look in forum865

 

[HughShane]

That sounds just what I need. Thanks a lot. I guess then, that samba only works within those permissions - shows how green I am over this!

I've run those commands (from my remote location) and will ask the site to carry out a test on Friday.

Would I have to re-run the commands if the server has to be re-booted? If so, is there a way of making them survive a re-boot?

 

[elgrandeperro]

I have had this problem before.

I think you need to also set the create mask to 775 and
force group.

But what I always do is create a crontab that sanitizes the path every 15 minutes. It is a find command that:

sets the directories to group X mode 775
set the group ownership to Y (g+Y)
set the file perms to 664

That way, even if samba does the wrong thing or someone uses ftp or scp, it fixes itself.

eugene

 

[HughShane]

I'm afraid I'm very slightly lost there!

OK, I create a crontab to run a script file every so often. The script file to contain, in my case:

chgrp -R feet /user/Common/DOCS
chmod -R 775 /user/Common/DOCS
(do I need some other commands here?)

Then you say to set the file permissions to 664 - I don't quite get that. Don't I want 775? I want the users and groups to have full permissions.

 

[Annihilannic]

775 gives them execute permissions, i.e. -rwxrwxr-x, which does no harm but doesn't really make sense for document files. 664 just gives them normal read and write, i.e. -rw-rw-r--.

They do however need execute permissions to directories to access them, so you could do this instead:

[tt]chgrp -R feet /user/Common/DOCS
find /user/Common/DOCS -type f | xargs chmod 664
find /user/Common/DOCS -type d | xargs chmod 775[/tt]

Annihilannic.

 

[elgrandeperro]

Thanks annihilannic, exactly.
I like the use of xargs.

eugene

 

[HughShane]

Thank you so much. I think I understand that now. I'll set that up tomorrow morning and get them to test it, then I'll report back.

 

[danomac]

When I did this, I set the group sticky bit on the directory. If all users are in the group feet, make sure that the directory that's being shared is in that same group and set the group sticky bit. This will ensure that all files created will inherit that of the parent.

So,

chgrp -R feet /user/Common/DOCS
chmod g+s /user/Common/DOCS


-d

 

[Annihilannic]

Yep, that's a good idea. On Solaris I used to use ACLs to set default permissions as well as ownership, which was very handy. I haven't figured out how to do this reliably on Linux though, the ACLs seem to have different semantics; if anyone knows how, do say!

For example, this is what I would do on Solaris to ensure files created in dirname had group write access:

[tt]setfacl -m "default:u::rwx,default:g::rwx,default:r-x,default:m:rwx" dirname[/tt]

Err... actually... I just tried it on SLES9 and it works fine:

[tt]$ mkdir testdir
$ ls -ld testdir
drwxr-xr-x 2 me users 48 2008-02-29 11:45 testdir
$ setfacl -m "default:u::rwx,default:g::rwx,default:r-x,default:m:rwx" testdir
$ ls -ld testdir
drwxr-xr-x+ 2 me users 48 2008-02-29 11:45 testdir
$ touch testdir/testfile
$ ls -l testdir/testfile
-rw-rw-r--+ 1 me users 0 2008-02-29 11:45 testdir/testfile
$[/tt]

Maybe I was thinking of some other ACL feature... anyway, the above may be useful for you.

Annihilannic.

 

[TonyGroves]

It might be a good idea to tune the find command so that it caters for files with spaces in their names:
[tt]
find /user/Common/DOCS -type f -print0 | xargs -0 chmod 664
[/tt]
and similarly for directories.

 

[elgrandeperro]

Yeah, I could not find a reference that says Linux g+s behaves like Solaris, so I did not mention it. It usually is in the chmod(1) man page. Where is that referenced or is that tribal knowledge?

eugene

 

[danomac]

eugene:

A long time ago (90s sometime? been a while) I searched for ways to deal with this problem. I think I did a `man -K SGID` or something to that effect which had information that described this behaviour.

I did, however, locate it again on tldp.org (for those that don't know - The Linux Documentation Project.) It has the same file security information I found way back when. To quote from section 3.4.2.5 Special Modes:

SGID (set group ID) on a directory: in this special case every file created in the directory will have the same group owner as the directory itself (while normal behavior would be that new files are owned by the users who create them). This way, users don't need to worry about file ownership when sharing directories:

I did forget to mention that if you copy existing files to the directory with the group sticky bit, the original permissions are retained. This combined with the "force group" in samba applied to the right share should fix the problem the OP has.

 

[HughShane]

I've run the commands suggested by Annihilannic at 28 Feb 08 17:56 and expanded on by TonyGroves at 29 Feb 08 2:20 as to files and directories with spaces (they do have them all over the place!). As there' no one on site at the moment and I'm visiting site on Saturday, I'll give this a thorough going over then. If I need to, I'll try the setfacl as well but I have lots of other stuff to do while there. So I'll get back after the weekend folks.

Again, many thanks for helping out so far with what I thought would be an easy thing!

 

[elgrandeperro]

Danomac, thanks for the reference (nice if it were in the man pages).

Forcing the mask, setting the g+s bit, forcing the group fixes like %95 of the problem. But you get the smart user who scps/ftps/NFS/cps drops the file. You can't control the mask in that situation and the file usually gets set to the right group with the group write bit off.

Since the directory is group writeable, a user CAN move and replace but not overwrite the file. Since most samba users will drag and drop, this will give a permission error. (even though the operation could be performed by removing the file and rewriting it, that is not what drag and drop does).

So you still need the cron script (with all the above changes) to sanitize the directory and files.

Believe me, I have been through this before at a production deployment site and short of changing the code on all the ways a user can transfer the file, the script is pretty painless, unless the filesystem is huge and slow.

eugene

 

[HughShane]

I ran the following commands again at site:

chgrp -R feet /user/Common/DOCS
find /user/Common/DOCS -type f -print0 | xargs -0 chmod 664
find /user/Common/DOCS -type d -print0 | xargs -0 chmod 775

but the problem remains: if one user saves a Word document in the folder /user/Common/DOCS and exits, if then another user opens that document, it is still shown as [Read only].

I didn't have time to try the setfacl command, as there were more pressing things to be done there. I'll run it now from my remote location and see if there's any change on Monday.

Meanwhile, if it helps, I'll post the smb.conf, in case there are some conflicts there.

 

[QatQat]

I must disagree with Elgrandeperro,

setting group bit on the directory will fix the problem, even when a windoz user drags and drops on the directory.
Samba will allow users on a share after a form of authentication that will identify the user and therefore his group. The write permission for the group permits overwriting with no problem.

The g + s solution is, to my knowledge, the only sane one, and also the most elegant.
Running scripts is a solution that fixes the effects but not the cause.


QatQat

If I could have sex each time I reboot my server, I would definitely prefer Windoz over Linux!

 

[HughShane]

So QatQat, are you suggesting I should run:

chgrp -R feet /user/Common/DOCS
find /user/Common/DOCS -type f -print0 | xargs -0 chmod 664
find /user/Common/DOCS -type d -print0 | xargs -0 chmod g+s 775

If so, that's what I'll do.

I agree, I wish I knew what the cause of this is, so we could fix it at that level!

 

[QatQat]

You can run it to fix all files and dirs at once, but not as a cron script.

The point is to try and solve the issue, not mitigate the effects.

You have two sides of it, one is the group ownership which you will solve with g+s bit.

Other side is the default file permission that you can fix with a FORCE CREATE MODE line in your samba share definition in smb.conf.
If that does not work, you can always fiddle with umask for that directory. In the first way, samba daemon will set permissions, in the other way, the linux filesystem will force permissions, as per umask value.
Be careful because umask is set by removing bits from your 666 maximum directory permissions, and not by specifying them directly, so

umask 002 = chmod -R 664

QaTQat

If I could have sex each time I reboot my server, I would definitely prefer Windoz over Linux!