PDA

View Full Version : Samba shared library



JohnD
14-07-2003, 08:51 PM
I have running a Linux server in a school situation (set up for free!) using Samba. I need a folder for staff to share files. The section in smb.conf reads:

[LIBRARY]
Comment = some blah
path = /home/shares/library
valid users = user1 user2 user3 (real users in here)
public = no
writable = yes
create mask = 0770

All the people in the "valid users" line are in a group together (staff). The library folder has the following rights: drwxrwxr-x root staff.

The problem is that all can save files to the directory and view the files in Windows Explorer but files placed there by someone else cannot be loaded into an application (insufficient network rights or similar message).

Am I missing something simple here or is there a fault of some kind? I am using RH7.0.

John

cyberchuck
14-07-2003, 09:06 PM
What is happening is that when users create/move/edit a file, they are changing the ownership of that file from the group to themselves. This means that only they can access the file (with the exception of root).
What you will want to do to fix this would be to put all the staff into the same Group and make all new files accessible to the group...

You don't say what version of linux you are running, however, in KDE you should be able to right click on the folder (as root or a super user), click properties and go into the permissions tab (this is on RedHat 9 - most likely different for each distro).
Re-enable read, write and execute privilages to group users (which is already enabled) and put a tick in "apply changes to all subdirectories and their contents"
Otherwise you can do this in the console by using "chgrp -rv [groupname] [foldername]"
This is the short-term fix..
Although logging in as root and changing permissions would get annoying real fast real soon.

If your linux server has Samba converting Windows Usernames to Linux Usernames, then you can add all your staff into Samba under a generic account (which I'll call staff for this point in time) and that means that if jbloggs logs into windows and accesses Linux, then Samba converts jbloggs into staff and uses the staff account for reading, writing, etc. That means that mary can come along and the same thing will happen for her - therefore all your users can access the files...

Otherwise, if you use Linux based logins, then what you could do is tell your User Manager that the jbloggs and mary don't have their own groups for themselves, (which by default is their username), but they are also members of the staff group which is then set to their default group. Providing the group has read/write/execute permissions you'll then have no problem...

Sorry it's a bit waffly in places..
My comprehension of linux is still minimal at this point in time

CyberChuck

JohnD
14-07-2003, 10:43 PM
Thanks cyberchuck - I think I have done all that but will check again next time I go past the site.

John

patgade
15-07-2003, 02:26 PM
Hi,

After resetting the ownership and permissions of all the existing files, I would modify the share as follows:

[LIBRARY]
Comment = some blah
path = /home/shares/library
valid users = @staff
public = no
writable = yes
create mask = 0770
force group = staff

By using @staff rather than the list of users you wont have to modify the share everytime group membership changes.

The force group option will overide the users default group when creating files under that share meaning all members of the staff group can access all files saved there.

To truly enforce these settings, you can also look at:

force create mode = 0770
force directory mode = 0770
force directory security mode = 770
force security mode =770

Check the man for smb.conf for details on what these do.

Regards

Patrick

patgade
15-07-2003, 02:34 PM
By the way, Redhat 7.0 is very old. I'm not sure what version of samba came with that, but if I were you I would at least upgrade to 7.3 and then to the latest samba version (2.2.8) from
ftp://au1.samba.org/pub/samba/Binary_Packages/RedHat/RPMS/i386/7.3

Patrick

Graham L
15-07-2003, 03:31 PM
Another security bit which might or not be appropriate is the "sticky" bit. That enables anyone (in the "7") to read/write to a public directory but not to remove files deposited by others. (This would mean that files could be edited, but would have to be saved under a different name. You might have to trust your staff users. :D ). An example would be "mode 1770".

JohnD
15-07-2003, 09:10 PM
Thanks people - still haven't got back to check and try out some of the ideas but will do.

John

JohnD
15-07-2003, 09:20 PM
Last Christmas holidays I went into the school to upgrade from RH7.0 to 7.3. I had much trouble getting the method of dial on demand I have working on 7.0 to go on 7.3 and in the end decided to revert back! Tried an upgrade and a clean install.

JohnD
16-07-2003, 08:44 PM
Well it was the "force group = staff" that did the job - thanks