9 Replies Latest reply: Nov 24, 2007 6:59 PM by Ulrich_F.W. Ernst
Ulrich_F.W. Ernst Level 1 Level 1 (25 points)
Somehow, the Finder now requires an admin password every time I copy/drag an item on the Desktop to a folder, or drag it into the Trash. I'm running 10.5.1, with a wireless keyboard and mouse, from a MacBook. Is this a feature or did I do something wrong?

MacBook/MacBook Pro, Mac OS X (10.5.1)
  • biovizier Level 5 Level 5 (7,925 points)
    Is the password required for anything, or just certain things? There does appear to be a permissions bug in 10.5 with respect to the removal of folders under certain conditions.

    Otherwise, it might just be a generic permissions problem. The output from these commands, entered using "/Applications" > "Utilities" >"Termnal.app" might provide some information:<pre>
    id
    ls -del ~/Desktop</pre>
  • Niel Level 10 Level 10 (272,325 points)
    Click on the desktop in the Finder, choose Get Info from the File menu, and give yourself write access in the Ownership & Permissions section.

    (26192)
  • Ulrich_F.W. Ernst Level 1 Level 1 (25 points)
    Thanks much for the suggestions. I did of course make sure that I had read/write privileges for the Desktop -- that didn't so anything.I tried the Terminal option, and here's what I got: "group:everyone deny delete." I'll try some more. Thanks.
  • Niel Level 10 Level 10 (272,325 points)
    You need to use the chmod command to get rid of that entry in the ACL or the whole ACL. The delete right is required to move an item out of a folder.

    (26196)
  • biovizier Level 5 Level 5 (7,925 points)
    That's the standard ACE that Leopard seems to put on the top level elements of the user's home folder. There are a few differences in Leopard with respect to how user access to files and folders are determined, and access control lists are one of them. But it would be more helpful to see all of the information returned from the commands. If you are concerned about posting username information, include the '-n' option:<pre>
    id -u
    ls -deln ~/Desktop</pre>

    Also, pick out a few items that present the problem and run 'ls' on those as well, including quotes as shown if any present a "no such file..." error. Eg:<pre>
    ls -deln ~/Desktop/"name of item"</pre>

    One possibility is that "Get Info" was used to apply the permissions on the "home" folder, or one of the top-level user folders, to "enclosed items". This would propagate the ACE onto every item, preventing literally "everyone" from deleting anything.
  • Ulrich_F.W. Ernst Level 1 Level 1 (25 points)
    I truly appreciate the assistance and suggestions. I have to confess my knowledge of UNix is limited, although I'll be happy to learn. Here is the response to the Desktop line: drwxrwxr-x+ 77 501 20 2618 Nov 22 21:14 /Users/uernst/Desktop
    0: ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000000C deny delete.

    And the one for a particular file: -rwxrwxr-x@ 1 501 20 2051072 Oct 24 04:16 /Users/uernst/Desktop/UMA
    0: ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000000C deny delete.

    Basically I do not have privileges to change change the name of any file on on the Desktop, even after I move it to another folder (using my password). I had an earlier problem with saving a custom template under Pages, because I did not have privileges to save anything to the Library/Applications Support folder. I took it to the local Apple Store where the genius fixed it by adjusting permissions.
  • biovizier Level 5 Level 5 (7,925 points)
    Well, if they are responsible, the "genius" may have messed things up!

    An ACE of 'group:everyone deny delete' will prevent that item from being removed. The effect is different from that of permissions, where the absence of "write" privileges on a folder is supposed to prevent the contents from being deleted (but not the folder itself) - the "delete" rule prevents the item itself from being deleted (or renamed) but should not affect the ability to remove contents. Probably in response to reports of people accidentally messing up their own "home" folders, Apple has added this ACE to "home" folder and top level folders of users' "home" directories. In this case, at least for the file "UMA", it also has that ACE.

    While ACLs can be set to be inherited, this is not the case by default, and your "Desktop" folder does not have this set. So it must have been applied manually, probably when the adjusted the permissions.

    Since you only mentioned having problems with the "Desktop" folder, I will assume that is the only one that was treated in this way. Furthermore, assuming that you haven't intentionally applied any ACLs yourself, and assuming you own everything on the "Desktop", try these commands - the first will remove all ACLs from everything on the "Desktop" (including the contents of subfolders), and the second will restore the default ACL to the "Desktop".<pre>
    chmod -RN ~/Desktop
    chmod +a "everyone deny delete" ~/Desktop</pre>

    As an aside, the permissions on the "Desktop" allow members of the group "staff" privileges to "write" - note that that is atypical as well, being a little less private than the default setup. User 'chmod g-w ~/Desktop' if you prefer the default setting.
  • Ulrich_F.W. Ernst Level 1 Level 1 (25 points)
    That did it! Grateful for the guidance. Thanks.
  • Ulrich_F.W. Ernst Level 1 Level 1 (25 points)
    Apparently, whatever the Apple Store Genius did also affected my principal document storage, Using the template for restoring privileges, I managed to fix that as well. Good to know there are people out there who (a) know what they're doing, and (b) are ready to help. Thanks mcuh.