Apple Support Communities > Servers and Enterprise Software > Mac OS X Server v10.4 and earlier > Discussions
This discussion is archived
4984 Views 11 Replies Latest reply: Nov 24, 2005 2:17 AM by Gerrit DeWitt
Currently Being ModeratedSep 30, 2005 10:30 PM (in response to Gerrit DeWitt)Even More Details
â¢ While logged in as a user with a network home, you can mount the home again via Connect to Server, mount the other share point, and copy from one to another successfully from the Finder. Copying from the other share point to the user's home via cp or ditto works as expected. For this reason, I think we're dealing with a Mac OS X 10.4.2 Finder bug, possibly as a result of some signal that the Mac OS X Server AFP process is giving it.
â¢ The previous two points lead me to believe that the problem with "insufficient privileges" is related to how the user's home directory is mounted. This would explain why the problem is client-specific and specific to 10.4.2. It seems that in 10.4.x, network home automounts (dynamic automounts) are actually mounted to /private/Network/Servers/*, just like in Mac OS X 10.3.x. However, in Mac OS X 10.3.x, /Network/Servers pointed to /private/Network/Servers; in 10.4.x, /Network/Servers points to /automount/Servers, which points to /private/Network/Servers.
â¢ Changing the umask has nothing to do with this problem as far as I can tell, since privileges are set correctly and a copy from another share point to the home (when mounted manually via Connect to Server).
â¢ Security Update 2005-008 (1.0) released 2005-09-22 does not correct the problem for Mac OS X 10.4.2 clients.
Currently Being ModeratedOct 23, 2005 12:41 AM (in response to Gerrit DeWitt)This issue also occurs with 10.4.2 clients that do not have network homes, and whether they:
A) connect to a server sharepoint with POSIX permissions only (group = rw) and thereby the Inherent Permissions option turned on
B) A sharepoint on a different volume, with ACLs enabled and inheritence set as desired.
The issue as you describe still occurs.
It appears to be a very serious bug in the Finder in 10.4.2 client.
If you copy the file via ditto, the permissions should be retained correctly - give it a try
Currently Being ModeratedOct 23, 2005 11:26 PM (in response to davidh)If you copy the file via ditto, the permissions should be retained correctly - give it a try
That's correct - copying using cp works as well, as outlined above. I'm glad you agree that this is a 10.4.2 Finder bug!
Plus one for you... I will update if I find any more details, and your posts are welcome!
Currently Being ModeratedOct 24, 2005 8:26 AM (in response to Gerrit DeWitt)Further information:
Tested with our office server (10.4.2) and my machine (10.4.2) and setup a share such that the POSIX permissions had no bearing on (were completely distinct and seperate from) the ACL settings. IE: Owner = root (rw), group= admin (rw).
Setup a test group ("testgroup") with user1 & user2 and assigned an ACL for testgroup with rw permissions and those settings to be inherited.
Initially, I could not even put a file on the new share, as user1 or user2.
I used memberd -r
followed by memberd -l; cat /Library/Logs/memberd_dump.log
and the log did NOT show my new users listed at all.
Repeated the process, still no joy.
Restarted the server (BLECH) and then was able to write a file to the share as user1 (and/or user2) and permissions were handled correctly. Saved a file as user1 to the sharepoint and then connected as user2, copied the file over, worked on it and saved it, and copied it back to the share, replacing the original file, and user1 could still work on the file just fine: copy it over, edit it further and copy it back to the share.
The plot thickens...
Currently Being ModeratedOct 24, 2005 5:17 PM (in response to davidh)Were the users in question stored in the server's local NetInfo domain or a shared LDAP domain?
Currently Being ModeratedOct 24, 2005 6:29 PM (in response to Gerrit DeWitt)Both.
The existing user base is in the local NetInfo domain, however, I did authenticate as the Open Directory admin for the server and create two users and placed them in a group, within the OD/LDAP domain.
The issue persisted with those LDAP/OD users, I saw no difference in the symptom.
Currently Being ModeratedOct 24, 2005 6:36 PM (in response to Gerrit DeWitt)Worked again today on the first server where this issue was occuring.
The "FIX" is to restart the server.
made no difference in the problem.
After restarting, the ACLs worked as expected.
Note: Prior to this, for the sake of clarity in testing, I ensured that the settings for the POSIX permissions had no bearing on/intersection with, the ACL settings. For the ACL governed share, I set owner to root and group to Admin. Several normal users comprise the Group that was assigned RW access (with full inheretence) via ACLs.
And I tested with a sharepoint on a voluem with no ACLs ever enabled, using POSIX permissions only, and the AFP settings selected for the sharepoint being "Inheret permissions from parent"
Currently Being ModeratedOct 25, 2005 1:12 AM (in response to davidh)For the ACL governed share, I set owner to root and group to Admin
I think that's a good practice. I usually use root:admin or root:staff for most share points where ACLs are implemented. It makes troubleshooting easier.
After restarting, the ACLs worked as expected.
Would you mind trying to copy data while logged in as a user with a network home directory to see if you can replicate my original error? The copy-to-network home bug persists across restarts, even after ACL permissions are working correctly. Here's the procedure:
Log in as a user whose home resides on an automounted AFP share point (skipping setup details for brevity).
Use Connect to Server to mount another share point on your server. This other share point should have ACLs implemented, and you should connect as a user whose effective permissions are derived from an ACL entry there (e.g. as a user with an applicable ACL entry).
At this point, if the connecting user has read/write access or Full Control (or appropriate combination) for the newly-mounted share, copy to, create, and delete operations should work as expected on that share. (I'm guessing this didn't work for you until you rebooted your server.)
Now try to copy a folder of files from the mounted share point to the user's desktop. Do this a few times and see if you get an "insufficient privileges" error.
As always, I appreciate your feedback!
Currently Being ModeratedOct 25, 2005 1:16 AM (in response to Gerrit DeWitt)My problem is (related?), that students cant give files to each others or to teachers Drop Boxes.
Homes are on AFP, all on same partition. Server+clients 10.4.2.
When they drop files (move!) files keep givers ownership and reciever cant open it.
After all I read here about chmod and ACL (Thanks Gerrit), I understand that they HAVE TO copy (alt-drop) files on others Drop Box, as the file inherrit ownership upon creation.
Move files to Drop Box wont work, regardless if Drop Box use POSIX or ACL. Now Drop Box is no ACL, only chmod 4733.
If my understanding is correct, can I FORCE a drag to Drop Box to always copy instead of move?
Currently Being ModeratedOct 26, 2005 9:20 PM (in response to Gerrit DeWitt)Well, the answer in my case was to restart the server.
However, it turns out it's only necessary to umount & then remount the volume:
(see the "note" at the end)
Currently Being ModeratedNov 24, 2005 2:17 AM (in response to Gerrit DeWitt)This problem persists in Mac OS X 10.4.3.
--GerritApple Certified System Administrator, AuburnMac; ACN+ACA