up vote 0 down vote favorite
1
share [g+] share [fb]

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

link|improve this question
86% accept rate
User groups and other native permissions, don't chmod 777. – Warner Jul 8 '10 at 13:54
feedback

2 Answers

up vote 1 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.

link|improve this answer
Yet the post says he did that and it didn't work.... – Mistiry Jul 8 '10 at 13:49
1  
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
Yes, and to my knowledge I've done this. After reading repsonses I know what needs to be done (and I feel that I've done it), but apparently I'm missing something. Can you point me to a bit of info on something specific? Thanks, btw. – humble_coder Jul 10 '10 at 4:23
show 1 more comment
feedback
up vote 1 down vote

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
link|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
1  
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
feedback

Your Answer

 
or
required, but never shown
discard

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