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 have set up a debian box as a replacement for an old windows server for my company's central file repository. I am using acl enabled ext3 filesystem.

We need to be able to use extended access control lists to control user access to files, and windows users recognise the acl's set just fine.

Mac OS X clients (running leopard 10.5) will not see the extended ACL's via samba or netatalk and I run into permissions errors.

Can someone please recommend a way around this? How can I get Mac OS X to recognise extended ACL's on linux? I am happy to change from debian to something else if need be, just as long as it is free ;-)

share|improve this question
    
It seems that putting [global] unix extensions = no In my /etc/samba/smb.conf has helped matters a little, now the mac client doesn't see permissions at all and assumes read/write access for everything - then fails when trying to write to a directory it shouldn't be able to. Can anyone recommend any better work arounds? This seems a little hacky. –  bobinabottle Jul 22 '09 at 12:40
add comment

1 Answer

Try this workaround:

Add

acl check permissions = no

to [global] because of how Darwin ACLs are closer to Windows ACLs instead of POSIX ACLs.

Sources:

share|improve this answer
2  
Thanks for the tip, but doesn't seem to work for me. I have set standard unix permissions to no access, then the ACL grants access. With acl check permissions = no, the acl is disregarded, and no one has access! The work around I will have to go with is setting unix extensions = no. This lets the windows clients see ACLs fine, and the mac clients assume write capability to everything (until they try to write something). Directories they have no access to appear empty. Ideally, I'd like to use netatalk for afp access for the macs, but it won't see the ACL's either! Would a different fs help? –  bobinabottle Jul 23 '09 at 16:10
add comment

Your Answer

 
discard

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