13

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

Improve this question
1
  • User groups and other native permissions, don't chmod 777.
    – Warner
    Jul 8, 2010 at 13:54

4 Answers 4

Reset to default
14

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.

Improve this answer
10
  • 1
    Yet the post says he did that and it didn't work....
    – mistiry
    Jul 8, 2010 at 13:49
  • 2
    Then he did it wrong. It works.
    – Warner
    Jul 8, 2010 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, 2010 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, 2010 at 17:53
  • 2
    I've been looking for a long time for this! Thanks! :) It's working as expected.
    – NagyI
    Nov 18, 2012 at 14:33
2

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
Improve this answer
4
  • About the only situation where publicly writable is acceptable is with /tmp.
    – Warner
    Jul 8, 2010 at 13:45
  • 1
    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, 2010 at 13:50
  • 3
    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, 2010 at 17:18
  • 2
    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, 2014 at 6:01
2

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".

Improve this answer
0

From the comments of the accepted answer, it actually didn't solve OP's problem, and neither did the other answers, if OP happened to have the same problem as I did:

Having the share on an NTFS/FAT partition.

Remember this when plugging your desktop disk to a NAS for sharing your family albums: fs mount params for user, group, create modes etc. override whatever is configured for Samba! ;)

(E.g. in my case, regardless of smb.conf everything was created by root, with 777 – as per the fstab defaults for the NTFS fuse mount...)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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