How to Fix the Unknown Group (Permissions)

BACKGROUND

Leopard sets up accounts and permissions differently than Tiger did. In Leopard, users belong to the staff group, while in Tiger they each belonged to their own one-member group named with their short name. Leopard's installation script doesn't migrate the accounts, it just leaves them intact. For example, in Tiger, my XYZ account belong to the XYZ group. Leopard didn't correct that to the staff group (20) or define the XYZ group, so my files belonged to an unknown group. That causes problems with Spotlight and a lot of other stuff.

SOLUTION

The solution requires a separate admin account and enough disk space to make a copy of the home folder.

Prepare for this by unregistering your computer from dot Mac and logging out of it. Also, turn off the Time Machine.

1. Create folders in /Users/Shared that correspond to the folders in the home folder (Desktop, Documents, Library, and so forth)

2. Move the contents of each folder in the home folder to the corresponding folder in /Users/Shared. (For example, contents of Documents to Documents). You cannot just move the folders, because you won't be able to open them from another account.

3. Log off, then log into the separate admin account. Delete the troublesome account, and select the option to delete the Home folder. This is necessary because the troublesome account is irredeemable, and it's the only way you can reuse the short name.

4. Create a new account with the same name, short name, and password as the now-deleted troublesome account and log into it.

5. Open two Finder windows, Sharing and the current account's home folder. Move the files to the current account, but don't overwrite the top-level folders (Desktop, Documents, and so on), move their contents. If you cannot overwrite a folder, open it, and move the contents.

6. When you are working on the /Users/Shared/Library folder, move the Mail folder to the desktop so you can import the mail boxes into your new setup.

7. If you have more than one Mac and you have dot Mac, register the computer and sync now.

8. Import the mailboxes from the Mail folder on your desktop.

Now your user account is ready to use, almost indistinguishable from the old one, except all the permissions are correct and everything works well. There may be a few preferences here and there that you might have to reset.

9. I recommend using Disk Utility to erase the Time Machine disk so you can start over.

This isn't easy, but it less painful than erase-and-install followed by installing all your applications.

24" iMac and 15" MacBook Pro, Mac OS X (10.4.10)

Posted on Nov 18, 2007 6:11 PM

Reply
56 replies

Nov 23, 2007 6:51 AM in response to brian_c

Thought so. The fix to this problem is more complex than described by MacFixIt. MacFixIt specifically says to only to fix the home directory (which is why it did not fix new files created by TextEdit), so all your App's will also have the (unknown) user. If you run "sudo find / -group 501 -prune", you will see all files with GID 501.

I gave up on trying to fix this with Terminal. I cloned my Leopard drive, then I performed an Erase and Install, but _did not use_ Migration Assistant. I reinstalled my Apps that had original install discs (...and went through the 9 MS Office updates!), and for the rest I dragged over from the clone. I then copied all files from my home directory (following Ken' suggestions). I also examined the files in /Library/Application Support as some apps store their license key in that directory (i.e. Omni Outliner and Comic Life)

As you can see, most of what I did is what Ken suggested in the first post in this thread, with minor adjustments (i.e., no need to import my mail, as Mail will read the files copied to my Library just fine).

So, now that I've spent all this time to correct my GID to 20, Apple will probably push out a software update fix tonight 😉

Tony

Nov 23, 2007 7:25 AM in response to R C-R

Of course it is a "Finder" issue.

It most definitely is not an ownership / permissions issue - there is nothing wrong with the files - ' ls' knows exactly who owns what, and in case it wasn't obvious to those that used the workaround, so does ' /usr/bin/find'. It's "Finder.app" that has a problem with displaying the ones owned by groups that aren't on the system, or with "incomplete" (in Leopard terms) group records.

Seriously, anyone that doesn't get that is completely missing the point of the issue, though that isn't to say adjusting the group ownership of files and folders won't be a workaround - it should for most people.

Even though it essentially is a version 1.0 product, here we go again -- FTFF.

Nov 24, 2007 1:23 AM in response to Tony T1

Tony T1 wrote:
If you only clicked on the lock, then yes, finder will not crash. I received Finder crashes if I then attempt to remove the unknown user.


I have no crash problems with that either. The only glitch I see is that sometimes I can delete the "(unknown)" group entry via the Finder's Get Info permissions section & sometimes I can't. The second is the expected behavior since a file must always be in some group. In the first, even though the Finder appears to let me delete the group entry, it actually gets assigned to group wheel (as verified by using the Terminal command "ls -l" on the file).

If I discover anything about why some group entries can be deleted from the Finder view, I'll post it but so for it just seems to be a cosmetic display problem in the Finder.

Nov 25, 2007 3:15 AM in response to Tony T1

Tony T1 wrote:
The fix to this problem is more complex than described by MacFixIt. MacFixIt specifically says to only to fix the home directory (which is why it did not fix new files created by TextEdit), so all your App's will also have the (unknown) user.


I'm not sure what you mean by this. Each user's Desktop is a folder in that user's home directory -- if you save a TextEdit file to the desktop, it is being saved in your home directory. Applications installed in the /Applications/ folder should be owned by system & in group admin (GID of 80) with read/write privileges for both -- this is what allows any admin user to install or remove them & prevents standard account users from doing so.

Files in /Library/Application Support (& files in /Library/ in general) should have the same access privileges for the same reason. Changing any of these will bypass the safeguards permissions is designed to implement & should be avoided unless you have a specific need to do so.

Moreover, setting appropriate permissions is a complex process, depending on file "mode" metadata & folder inheritance rules that the OS handles automatically. For example, mode flags can force files to be created in a directory with that directory's owner or group privileges, ignoring the privileges of the process that created them.

Unless you understand the nuances of this process, I suggest you not attempt to change permissions of anything not in your home folder, & to be careful about doing so in that directory, especially when recursively changing permissions of items in its sub-directories.

Nov 25, 2007 4:42 AM in response to biovizier

biovizier wrote:
Seriously, anyone that doesn't get that is completely missing the point of the issue, though that isn't to say adjusting the group ownership of files and folders won't be a workaround - it should for most people.


I think you are missing the point of my post: there should be no issue other than a Finder info display one if your OS is healthy. IOW, if the Finder crashes when trying to manipulate permissions, something more than this display issue is involved & your efforts should be directed at trying to find out what it is & how to fix it.

The "Get Info" display of "(unknown)" in the group permissions position of the list is not itself a problem. "(unknown)" does not mean the Finder thinks the file is a member of the "unknown" (GID = 99) group -- note that one is parenthesized & the other is not. This display is simply telling you what we already know, that the group has no name. The ls -l terminal command handles this by substituting the GID for the group name, just as if you had used the -n option. Presumably, Apple chose "(unknown)" for the Finder display rather than the GID as a more user-friendly way of representing this for those that don't want to delve into the arcane world of UNIX user ID's. Perhaps something like "no_name" would have been a choice less confusing for those that know about the unknown user, but maybe not. Whatever they choose needs to be short -- there isn't room in the Finder info display for a long, descriptive string. Frankly, I think "(unknown)" is as good a choice as any, at least once one notices the parentheses.

The only real bug I can find with this is the Finder sometimes appears to let me delete the group entry. When it does so, the group actually gets changed to wheel (GID = 0) but the Finder display doesn't update to show this -- there remain only the two entries displayed, one for owner & one for others. (I think this has to do with the privileges of the enclosing folder but I need to do more testing to be sure about it. So far, it appears that the only files that appear to allow this are those enclosed in a folder with the same two-line display bug, suggesting it is inherited from wherever Finder stores access display info for folders.)

However, in no circumstances I can generate does Finder crash or is there any mis-operation of any core service I can detect.

BTW, your comment "the ones owned by groups" is confusing. Groups don't own any files; they are just a way to confer a specified set of access privileges to a specified set of users other than the owner. This is something some posting here seem unclear about.

Nov 25, 2007 5:30 AM in response to Tony T1

Tony T1 wrote:
Does anyone know why Apple changed GID to staff (20) in Leopard?


First of all, it isn't that simple: in OS X the GID of newly created files usually inherits the group of the enclosing folder. (Flags can change this but usually aren't set to do so in folders users have write access to.) Not all *NIX's do this, but generally it is considered user-friendly behavior for Apple's target market, since typical users don't have to worry about (for example) setting appropriate group permissions for /Users/Shared/ items or items created in /Library/, which should not be in the staff group.

With that in mind, the question reduces to why newly created home folders are now by default in the staff group instead of their own, one-user groups. As it turns out, the staff group assignment is more or less the norm for various UNIX flavors & in fact the early versions of OS X did this. At 10.2 or so, Apple changed to the one-user group behavior & is now changing back to the more typical one. Just why is speculative but I believe the reasoning most accept for the first change was Apple decided a default staff group assignment offered less privacy for typical users not familiar with UNIX & those that were could change the behavior if they really needed a staff group.

There are several reasons why Apple might have changed back to the original behavior. I suspect it has partially to do with standardized UNIX compliance, partially with the greater ease of use of creating ACL's for more granular access control. It may simply be that Apple decided that more Mac users now have staff-like user environments and/or the OS is secure enough due to other improvements & refinements implemented in Leopard. Take your pick, I guess.

The new Guest Account in Leopard is UID:201 GID:201 I wonder why Apple didn't give it a GID of 20?


Probably because a guest would rarely be considered part of the staff, even if the staff is just the members of a family.

Nov 25, 2007 7:14 AM in response to R C-R

TextEdit uses a special folder also causing GID issues. Must be where it stores its temp file. Point is, OS X does things behind the scenes that most of us are not aware of, so the MacFixIt fix, does not work. More info here: http://discussions.apple.com/message.jspa?messageID=5867774#5867774

I'm not sure what you mean by this. Each user's Desktop is a folder in that user's home directory -- if you save a TextEdit file to the desktop, it is being saved in your home directory. Applications installed in the /Applications/ folder should be owned by system & in group admin (GID of 80) with read/write privileges for both -- this is what allows any admin user to install or remove them & prevents standard account users from doing so.

Nov 25, 2007 7:22 AM in response to Tony T1

Tony T1 wrote:
TextEdit uses a special folder also causing GID issues. Try creating a file and save it to Desktop and then check the permissions.


As I said, I've tried that & seen no problems associated with it whatsoever. The /private/var/folders/ item that stores files temporarily should not have anything to do with it -- it is a system-owned & managed directory with no regular (non root) user write access, group or otherwise. Users should not be trying to directly change anything in it, just as they should not with other directories they don't own.

What sort of "GID issues" do you see that you attribute to this or any other automatic backup function? Why do you believe it is associated with group permissions, unnamed GID's, or whatever?

Nov 25, 2007 7:45 AM in response to R C-R

Unless you understand the nuances of this process, I suggest you not attempt to change permissions of anything not in your home folder, & to be careful about doing so in that directory, especially when recursively changing permissions of items in its sub-directories.


Agreed, but changing only the home folder groups (as suggested by MacFixIt) does not fix the Unknown Group (Permissions) problem (as demonstrated by files created by TextEdit).

In my opinion there are only 2 ways to fix this problem:

_Solution #1_:

Clone your Leopard HD and Erase and Install and _do not_ use Migration Assistant.

Manually install you Apps from the original install disks, or drag and drop from the clone.

Drag and Drop all of the folders within your home directory from the clone (i.e., don't
copy the Home Folders Library Folder, copy the Folders within it (see the first post
in this thread).

Look in /Library/Application Support for folders to copy in order to retain your Licenses
(i.e. the plasq folder has the License for Comic Life)

See the 1st post in this thread for anything I missed here (...however, no need to import
your mail boxes for Apple Mail as they will be copied over when you copy your Library.

_Save Your Clone_ for anything that was missed that may not be immediately evident.
.
.
_Solution #2_: Wait for Apple to Fix the problem.

Nov 25, 2007 7:54 AM in response to R C-R

As I said, I've tried that & seen no problems associated with it whatsoever.


I've seen this myself, and every post I've from users who only changed the Home Folder GID has seen this (...but this is only based on the few who have posted and that I've read). The GID issue is that files created by 501:20 are set as 501:501.

This is better described here: http://discussions.apple.com/thread.jspa?messageID=5798887&#5798887 "While Leopard is a bit buggy, I love many of the new features. For instance, I just tried tracking file I/O activity on TextEdit using Instruments, and found that AppKit doesn't actually write the file directly to it's destination. Instead, it writes to /private/var/folders/pp/ppLi18jIF0yqSKTcKuJge ++TI/TemporaryItems/(A Document Being Saved By TextEdit)/anothertest.rtf (I'm sure that will vary between users), and then moves the file to its destination. By writing the file to that temporary folder, it gains the group of the folder that contains it, which did not change when you did the "chown -R <username>:staff ~", because it's outside of ~. Since that TemporaryItems folder still has group 501, the file gets group 501 (those are the semantics of open on Unix). Then it's copied over to it's final destination, but retains group 501."

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

How to Fix the Unknown Group (Permissions)

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.