Samba Permissions: a perennial problem?

Hello All,

I had earlier asked for help in setting up a PDC/fileserver using Suse 11. I’m glad to say I got it right and now 10 windows boxes access the shared directory (XFS) which i have mapped as a drive.

The problem is that at times certain machines create directories which cannot be overwritten/renamed/deleted by other users. This I usually solve by accessing the server and right-clicking the folder and re-sharing all over again with create and delete permissions for all users. It works of course but why does this problem persist (albeit randomly and out of the blue)?

Can you post the share’s configuration as defined in smb.conf?
Can you also show the Linux permissions on the shared directory?

yes i will.
thank you swerdna for the PDC config. I used the recipe from your website :slight_smile:

This is /etc/samba/smb.conf

[global]
domain logons = yes
domain master = Yes
netbios name = FILESERVER
os level = 255
preferred master = yes
security = user
wins support = yes
workgroup = VSLAN
include = /etc/samba/dhcp.conf
passdb backend = smbpasswd
usershare max shares = 5000
[homes]
valid users = %S
read only = no
browseable = no
create mode = 0600
directory mode = 0700

[projects]
comment = Work In Progress
inherit acls = Yes
path = /server/Projects
read only = No

If one user (windows box) creates a folder inside the share, the other machines cannot create/edit/rename it as the permissions remain with the user who created it. What is my mistake here? Each time I have to change that particular folder’s permissions from the server :frowning:

I assume the share is projects:

[projects]
comment = Work In Progress
inherit acls = Yes
path = /server/Projects
read only = No

Suppose there is a Linux user called “someone” on the computer. Make someome to be a member of the Samba user database [smbpasswd -a someone]. Make the directory Projects to be owned by user=someone group=users. Make the permissions on directory Projects to drwxr-xr-x. Change ownership of every file in Projects to user=someone, group=users. Make the share like this:

[projects]
comment = Work In Progress
path = /server/Projects
read only = No
force user = someone

All the users can still connect as they used to connect. But they will take on the personality of “someone” in the share. Anything they do there, even though they are not “someone” will be carried out as if they were “someone”.

Thereafter, everything created or edited or deleted in the share will be done as if by “someone” – and the problem will go away.

oops… i just found another fix which i tried and it seems to work :slight_smile: is it a roundabout fix or is it the same?

[global]
map to guest = Bad User
usershare allow guests = Yes
[transfer]
comment = writeable
inherit acls = Yes
inherit permissions = Yes
path = /home/me/Transfer/
public = Yes
directory mask = 0777
create mask = 0666
browseable = Yes
guest ok = Yes
writeable = Yes

Well done! It’s not even a related solution, but if it gets the job done, that’s great. You might have created a burden for administators if there are many users creating objects in the share:

directory mask = 777: if a user creates a directory it is drwxrwxrwx (except this is overridden by ‘inherit permissions’)

create mask = 666: if a user creates a file it is rw-rw-rw- (except this is overridden by ‘inherit permissions’)

inherit permissions = yes: overrides “directory mask” and “create mask” so that directories and files created by users will take on the mask of the directory “Transfer”. I think this will make “directory mask” and “create mask” as if they hadn’t been used.

guest ok = yes: allows access to anyone who can connect to the LAN, external or internal, without authorisation. You might see files and directories appearing with owner=nobody, group=nobody.

inherit acls = yes: child objects receive their access controls from the parent directory. I’m not sure how this mixes with “inherit permissions”. It becomes a bit much for my 2K processor to figure.

The template I suggested has two advantages: security (guests can’t access project data – everyone must authenticate) and tidiness (objects have standard unix permissions and ownership of everything resides with the project identity “someone”).

But I believe the old adage: whatever works, works.