Skip navigation
This discussion is archived

AFP Insufficient Privileges Error - 10.4.2 Finder Bug

4984 Views 11 Replies Latest reply: Nov 24, 2005 2:17 AM by Gerrit DeWitt RSS
Gerrit DeWitt Level 4 Level 4 (3,900 points)
Currently Being Moderated
Oct 26, 2005 9:20 PM
The following procedure details how to get an insufficient privileges error when copying files from an AFP share point mounted by a Mac OS X 10.4.2 client computer:

1. Server setup: Mac OS X Server 10.4.2 configured as an Open Directory master. Network home directories set up and clients bound to the server as per Apple's guidelines in the File Services and Directory Services Admin Guides. Installation of Security Update 2005-007 v 1.1 or Security Update 2005-008 does not affect performance. One network home directory share point, one additional share point configured. For the user account concerned, the user needs at least read access to the additional share point by virtue of an ACL entry. Apple home directory default POSIX permissions remain for the home. Both the home and the additional share point reside on the same HFS+ volume (or RAID volume) with ACLs enabled. Kerberos disabled.

2. Client setup: Mac OS X 10.4.2 with or without Security Update 2005-007 v 1.1 or Security Update 2005-008.

3. Log in as a network user to a client computer and mount the share point. Attempt copying a folder with files in it to the user's home (or a folder therein).

Occasionally, you'll receive an "insufficient privileges" error, claiming that the user does not have sufficient privileges to the current file being copied. Sometimes the copy will be successful; to increase the probability of getting the error, perform the copy test while more than one user is connected to the same additional share point.

In my testing, copying only fails when the source is a mounted AFP volume and the destination is an automounted home directory share point. In fact, it doesn't matter if the source volume is a static AFP automount; as long as the destination is an automounted home, the copy fails.

Conversely, copying from a mounted AFP volume to another manually mounted AFP volume or a local folder works without error. This leads me to believe that the problem is with the destination - a dynamic automounted AFP home folder share point.

More Details

• The error is client-specific, affecting Mac OS X 10.4.2 clients only. The error is not the result of a bad installation of client or server software, nor is it the result of damaged permissions or filesystem errors. A new installation of Mac OS X Server and Mac OS X 10.4.2 via Erase & Install will exhibit the error.

• I've been using the inheritance options available in ACLs to achieve new file and folder permissions for share points hosted with Tiger Server, and that works well. However, I still get "insufficient privileges" when copying files from the share point to a user's home directory (where that home directory is a network-mounted AFP home).

• It doesn't matter whether you leave the user's home directory privileges to Apple POSIX defaults or if you implement a Full Control ACL entry for the user on his or her home.

• The "insufficient privileges" error seems to be caused by something other than wrong permissions. Often attempting to copy a folder from a share point to the user's network-based home fails, but trying again works. If the copy fails again, it can fail on a different file. For example, if you copy a folder called "data" from a share point to the user's network home while logged in as that user, the copy may fail, stating that any one of the files in the folder has insufficient privileges.

• While logged as a user with a network home, it doesn't matter if you connected to the server to as that user again, guest, or as another registered user to mount the share point. Even with masked AFP permissions when connecting as another user, the copy from the share to the home still fails. In fact, it doesn't matter if the share point is automounted (by guest or securityagent via static mount).

  • davidh Level 4 Level 4 (1,890 points)
    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
  • davidh Level 4 Level 4 (1,890 points)
    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
    lookupd -flushcache

    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...
  • davidh Level 4 Level 4 (1,890 points)

    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.
  • davidh Level 4 Level 4 (1,890 points)
    Worked again today on the first server where this issue was occuring.

    The "FIX" is to restart the server.

    Again, using
    $memberd -r
    followed by
    $lookupd -flushcache

    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"
  • Joachim Schmidt Calculating status...
    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?

  • davidh Level 4 Level 4 (1,890 points)
    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)


More Like This

  • Retrieving data ...

Bookmarked By (0)

This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.