Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm having an issue with my install of Ubuntu 9.10 (file server) and its samba permissions. Logging in and reading works fine. However, creation of new directories by users restricts access for other users. For instance, if Bob (Windows user who maps the drive) creates a folder in the directory, Jane (Mac user that simply smb mounts) can read from it, but can't write to it -- and vice versa. I then must go CHMOD 777 the directory for everyone to be happy. I've tried editing the "create/directory mask", and "force" options in the smb.conf file but this doesn't seem to help.

I'm about to resort to CRONTABing a recursive chmod routine, although I'm sure this isn't the fix. How do I get all new items to always be 777? Does anyone have any suggestions to fix this ever-occurring situation?

Best

share|improve this question
    
User groups and other native permissions, don't chmod 777. –  Warner Jul 8 '10 at 13:54

3 Answers 3

up vote 7 down vote accepted

I typically use SAMBA's native functionality for permissions and groups management on shares. For example..

force user=user1
force group=sharedgroup
create mask=775

You would specify these settings under the share. Be certain to reload SAMBA after the configuration change, which could be done via the init script.

share|improve this answer
    
Yet the post says he did that and it didn't work.... –  Mistiry Jul 8 '10 at 13:49
2  
Then he did it wrong. It works. –  Warner Jul 8 '10 at 13:53
    
I'm not sure what's up. I've tried it manually and via Webmin to no avail. Perhaps my group choice of group is wrong? I've tried using "users" as well as various manually created groups, of which all have been made members. Regardless of what I do, users can't manipulate anything they didn't place themselves. The only "solution" is to have all users log in (or mount) as GUEST which produces confusion. –  humble_coder Jul 8 '10 at 17:13
    
SAMBA uses a combination of filesystem permissions and settings within the configuration. If users aren't on a write list or otherwise allowed to write in the share configuration, it will not work. If the user that SAMBA runs at is unable to access the directories, it will not work. Users should be members of the appropriate group, the directories and files should be owned by that group, and have the writable bit set for the group. You can check the SAMBA logs as well. –  Warner Jul 8 '10 at 17:53
1  
I've been looking for a long time for this! Thanks! :) It's working as expected. –  NagyI Nov 18 '12 at 14:33

Set the permissions on the directory to be 2777, like this:

chmod 2777 /shared/dir

This causes all files and folders under the '/shared/dir' directory to inherit the permissions of the top directory, in this case 777.

Afterwards, do this to make sure all files have the proper permissions:

chmod -R 777 /shared/dir
share|improve this answer
    
About the only situation where publicly writable is acceptable is with /tmp. –  Warner Jul 8 '10 at 13:45
    
Yeah, probably better to use 774 or even 770, depending on the situation. But, he asked how to make them all '777', so I just used that in my example. –  Mistiry Jul 8 '10 at 13:50
2  
Yes, but how do I ensure that all future files copied to that directory over the network receive the same permissions regardless of their initial permissions? I have no problems when manually doing it, I simply want it automated. –  humble_coder Jul 8 '10 at 17:18
    
This does not work. The setgid flag for folders sets the group of new files and folders, not permissions, and running chmod all the time is not acceptable. I need a solution that is not related to samba, for Steam on Linux so I can share library between users. –  Sam Watkins Jul 11 at 6:01

I realize this is an old question but I recently had a similar issue and here's how I solved it:

[share]
security mask = 0770
create mask = 0770
force create mode = 0660
comment = Samba share for IT
path = /raid/share
browseable = YES
guest ok = no
write list = root, @"DOMAIN+it_nfs"
force group = DOMAIN+it_nfs

This ensures that users have to be in the "it_nfs" security group in AD, all files will be written with group "it_nfs," and all files will be written with at least 0660 and at most 0770 perms. Forcing the group ID ensures that anybody in that group can read/write the files on the share. Otherwise you end up with situations where a file written as bob:bob can't be written by charlie:charlie, even though both of them are in "it_nfs".

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.