You can make a difference in the Apple Support Community!
When you sign up with your Apple Account, you can provide valuable feedback to other community members by upvoting helpful replies and User Tips.
When you sign up with your Apple Account, you can provide valuable feedback to other community members by upvoting helpful replies and User Tips.
I'm having really strange issues with Lion Server. Since upgrading to 10.7.3 I no longer have permissions to modify files on Share Points that I was once able to in 10.7.2. When I go to modify certain files or folders I get "The operation can’t be completed because you don’t have permission to modify some items."
Mac mini, Mac OS X (10.7.3)
How do you manage the permissions?
Are you assigning permissions to groups of which you are a member or do you assing permissions on user level?
If you are assigning them on group level try to see what happens when you add an user with the proper permissions to see if the server is mis interpretting the group ACL
I see this as well. I spent a ton of time recreating groups and ACLs last weekend after they suddenly stopped working; it worked for 4 days and then failed at midnight last night. What I see is that an OD group used in an ACL is suddenly ignored. This even applies if I log in a user directly to the server.
So, for example, lets say I make a directory "testdir" owned by root and with rx permissions for the group testgroup. I add an ACL, the only ACL, to the directory granting that group full permissions. The ACL is ignored—the user cannot create a file in the directory. If I grant write permissions via the POSIX bit to the group, write permissions return. If I create a new OD group and add an ACL using it, or add an ACL using a local group like staff, it works. Again, all of this is being tested locally on the server (of course it fails over shares, too).
I have an equal issue.
It seems leike the Server does the ACL inheritance right but die "File sharing" Service doesnt like them and ignores them.
Anyone a guess?
same problem here, anybody found a solution?
My workaround is to create local (not OD) groups on the server via Workgroup Manager, and only use the local group in ACEs. Then put the OD group into the local group, and users into the OD group. This has been working fine for me for over a month now.
ok, that works, thx. a pitty nobody found the reason for this behaviour. od users work, only group ace´s are ignored. when creating a new od group and adding a user, the ace is honoured until reboot. kind of odd...
I have a bug report open with Apple on it and they actually followed up a couple of days ago. So hopefully it gets fixed.
I fixed my problem.
I m using a Promise Raid as external Raid via Thunderbolt.
I had all my volumes at the root Layer of the Drive
!!! This did not work !!!!!
for example:
/Volumes/promiseraid/share1
/Volumes/promiseraid/share2
/Volumes/promiseraid/share3
!!! This works !!!!!
/Volumes/promiseraid/data/share1
/Volumes/promiseraid/data/share2
/Volumes/promiseraid/data/share3
Dont ask me why but with one folder layer in between it worked pretty well!
any news?
Brian your solution worked for me. From all the rumors 10.7.4 is due to release soon.
As I think more about it this issue might be related to another one I am having with groups. When I select user in the new Server app I cann see the individual groups which each member belongs to. However when I look at each group, no member is listed underneath it. Brian if you have some time, can you look to see if you are having the same behavior?
Hi Dave, I'm glad it worked for you too. However I just checked Server.app and the impacted groups do correctly list their members.
Thanks for checking Brian. I was hoping there was some pattern or relation to the two problems.
--Dave
hi!
thanks brian for the workaround!
i had the same problem with 10.7.3 and i hoped 10.7.4 will get this work. but i updated today and nothing changed. it ignores one od-group all others works fine. strange.
jochen
Background
Access Control Lists (ACLs) are applied to folders and files to define user (and group) access privileges.
I have setup two Mac mini Servers at our company – one in our Melbourne office and one in our Sydney office. Each file server is made up of the following hardware:
1x Mac mini Server (with Lion Server).
2x Promise Pegasus 12TB (6x2TB) R6 RAID System (thunderbolt) in RAID5 configuration. The two Pegasus unit are mirrored (RAID1) using SoftRAID.
Users and Groups are replicated between the two servers via Open Directory.
The PeachPit book "OS X Lion Server Essentials" is the best book I've found that explains OS X Server services and configuration. It has a good explanation of POSIX and ACLs.
The Problem
It seems there is a bug in Lion Server that causes ACLs be ignored. A couple of times I've managed to fix the problem using these steps:
1. Remove the share-point.
2. Setup up the share-point. /Volumes/promiseraid/work
3. Apply an ACL to a folder.
5. Propagate the ACL to sub-folders.
When ACLs are not applied to a folder the older POSIX permission define access privileges. With POSIX mechanism the user, group and other access privileges applied to new files and folders is defined in the 'unmask' value. The default 'unmask' value sets file/folder group to read-only access. The upshot is when POSIX mechanism is used and a member of staff creates a file or folder it is read-only to colleagues. System Administrators shouldn't need to change the 'unmask' value – too technical. Apple documentation encourages System Administrators to use ACLs to define access privileges – use ACLs to overcome the limitations of POSIX.
The workarounds I've been considering
A solution?
Scanning the several threads here I think I discovered a "fix". Mac OS Lion doesn't seem to honour ACLs if
However, if the folder being shared is at least one folder deep ACLs seem to be honoured!
!!! This did not work – ACLs are not honoured !!!!!
/Volumes/promiseraid
/Volumes/promiseraid
/Volumes/promiseraid
!!! This did not work – ACLs are not honoured !!!!!
/Volumes/promiseraid/share1
/Volumes/promiseraid/share2
/Volumes/promiseraid/share3
!!! This works – ACLs are honoured !!!!!
/Volumes/promiseraid/shareditems/share1
/Volumes/promiseraid/shareditems/share2
/Volumes/promiseraid/shareditems/share3
Acknowledgement
I should acknowledge gmbion for his time troubleshooting this and reporting his findings to this thread.
A response from Apple
It would be good if Apple could address this limitation with either:
Thanks everyone for your troubleshooting. We are going to upgrade our client systems to Lion.
The Mac Mini server now runs Lion 10.7.4 Server and users reported issues with File shares permissions.
The shares are also stored on a Promise Raid connected with thunderbolt.
Would the thunderbolt connection have any influence on that issue ? I know it doesn't seem to be a hardware issue at all, but I just noticed we were having this issue on Promise Raid systems conencted with Thunderbolt.
Lion Server 10.7.3 file sharing permissions
