Ashley Aitken

Q: The "Fetching..." problem

I'm currently plagued by the "Fetching..." user id and/or group id problem, wherein Mac OS X "Get Info" reports it is fetching the user id and/or group id but nevery successfully does.  This seems to cause problems (e.g. logging in if it is a home directory, amongst other things).

 

There are many threads and Web pages about this problem but it seems no-one has a solution or even a good understanding of what is happening.  I have seen it for user id and group id.  This is a new install of Mavericks and Mavericks Server that is running ok besides this problem.

 

My post relates to understanding what part of the OS is causing this problem.  Unix permissions (at least the basic ones) look fine and correct, i.e. from the command line I can see the user and group and they are correct, no problems (matching their numerical user and group ids etc).

 

Any yet Finder cannot fetch (I guess) the user and/or group name for some reason. Is this an Open Directory problem?  Is this a Finder problem?  Why can Unix seemingly see the name but the Finder can't (do they use different paths for the information)? 

 

Any thoughts / suggestions / fixes would be appreciated.

 

Cheers,

Ashley.

 

PS These users and groups were created fresh with a new install of Mavericks and Mavericks Server with specific ids I had used previously to match my separate "data" partition, which has the user home directories, folders and files.  However, the problem even shows on the boot partition. 

Posted on Feb 2, 2014 10:44 PM

Close

Q: The "Fetching..." problem

  • All replies
  • Helpful answers

  • by Linc Davis,

    Linc Davis Linc Davis Feb 2, 2014 11:15 PM in response to Ashley Aitken
    Level 10 (207,941 points)
    Applications
    Feb 2, 2014 11:15 PM in response to Ashley Aitken

    Unix permissions (at least the basic ones) look fine and correct

     

    What do you consider to be correct?

  • by Ashley Aitken,

    Ashley Aitken Ashley Aitken Feb 3, 2014 12:54 AM in response to Linc Davis
    Level 1 (39 points)
    iCloud
    Feb 3, 2014 12:54 AM in response to Linc Davis

    Hi Linc,

     

    The user id and group id have names and numbers that match (or are in line with access for) the user id and group id of the user I am logged in as. 

     

    I'm user 1001 with group id 1001 and the folder has user and group that match that.  However, when the Finder tries to show this info (or names for these numbers) in fails "Fetching..."

     

    I'm also seeing this elsewhere on another machine.  I can't remove a folder (directory) even though I have ok Unix permissions (i.e. rwx for the parent directory and the directory itself, which is empty). 

     

    It seems like Unix is showing one thing but the Finder is getting its info from somwhere else. 

  • by Linc Davis,

    Linc Davis Linc Davis Feb 3, 2014 6:37 AM in response to Ashley Aitken
    Level 10 (207,941 points)
    Applications
    Feb 3, 2014 6:37 AM in response to Ashley Aitken

    The group ID should be 20 (staff).

  • by Ashley Aitken,

    Ashley Aitken Ashley Aitken Feb 9, 2014 10:08 PM in response to Linc Davis
    Level 1 (39 points)
    iCloud
    Feb 9, 2014 10:08 PM in response to Linc Davis

    Thanks Linc, but I am not sure about that.

     

    The default Group ID is staff but I believe Apple enables admins to assign different groups as needed.

     

    Is it a requirement that users *must* be in the staff group for Mac OS X Mavericks to work properly?

  • by Linc Davis,

    Linc Davis Linc Davis Feb 10, 2014 11:09 AM in response to Ashley Aitken
    Level 10 (207,941 points)
    Applications
    Feb 10, 2014 11:09 AM in response to Ashley Aitken

    Is it a requirement that users *must* be in the staff group for Mac OS X Mavericks to work properly?

     

    Yes.

  • by Simon Slavin,

    Simon Slavin Simon Slavin Feb 11, 2014 6:39 AM in response to Linc Davis
    Level 4 (1,400 points)
    Feb 11, 2014 6:39 AM in response to Linc Davis

    To expand that a bit, don't mess with the Staff group.  Don't change its ID.  Don't change its GUID.  Don't remove accounts from it if the automated tools people accounts into it.  The word 'staff' is not really a good word for it, but it is just as needed as the 'wheel' group.

  • by Ashley Aitken,

    Ashley Aitken Ashley Aitken Feb 11, 2014 6:46 AM in response to Ashley Aitken
    Level 1 (39 points)
    iCloud
    Feb 11, 2014 6:46 AM in response to Ashley Aitken

    Thanks Linc and Simon, that is definitely good to know.

     

    I assume, however, that Staff doesn't have to be the *primary* group for all users?

     

    I will add it back for each user (if I actually took it away) but I would like to have our custom group as their primary group. 

  • by Simon Slavin,

    Simon Slavin Simon Slavin Feb 11, 2014 7:02 AM in response to Ashley Aitken
    Level 4 (1,400 points)
    Feb 11, 2014 7:02 AM in response to Ashley Aitken

    The primary group is a special group in Unix, and it used to influence how some things worked.  These days it is used to distinguish 'real' accounts from 'fake' accounts like 'diradmin' and 'www': humans have a primary group of 20, everything else doesn't.  Check this out by looking at the primary group of the local 'users' using Workgroup Manager.

     

    It can be unwise to mess with it.  Are there properties of the primary group are you trying to control ?  Do you need to change primary groups as opposed to making up your own groups and changing the membership of those ?

  • by Ashley Aitken,

    Ashley Aitken Ashley Aitken Feb 11, 2014 8:44 AM in response to Simon Slavin
    Level 1 (39 points)
    iCloud
    Feb 11, 2014 8:44 AM in response to Simon Slavin

    Simon, thank you for that explanation.  I believe I understand how Unix groups work and what the primary group means.  If that has changed "these days" then I may be getting things wrong. 

     

    I was using a different primary group because I wanted (the real) users in this group to share read/write access to various folder and files they create and use. 

     

    My understanding (of Unix) is that when you create a file or document it is given the primary group as its group id.  I find it hard to understand that Apple would mess with this underlying paradigm.

     

    I woud hope that if real people are in the staff group that should be ok for the MacOS.  Alternatively, I could try making our specific group inherit from staff (if that still means what I think it does). 

     


  • by koala_uk,

    koala_uk koala_uk Apr 4, 2015 6:32 AM in response to Simon Slavin
    Level 1 (0 points)
    Apr 4, 2015 6:32 AM in response to Simon Slavin

    I have only just encountered this problem as I only recently upgraded to Mavericks on one of my machines.  I have 2 machines still running Mountain Lion and none of the users belong to group "staff''.  The Finder Get_Info always shows the file permissions as I would expect given the unix file permissions and any additional acls. I dont see this "Fetching..." problem. 

    But Mavericks is a nightmare.  The upgrade changed the name of an existing group id and gave it the same name as one of the users. (group id 1001 spider is now called ben). It then gave that group name a different id (group id 103 was added, called spider and included noone).  All the unix file permissions ended up with "unknown" group. I have been trying to sort out the mess ever since. The "Fetching..." problem only became apparent while I was trying to do this.

    I have used Unix for over 30 years (in fact I only started buying Apple machines when they started using something underneath I was familiar with) so I would like to know WHY all real users have to be in the staff group now.  They certainly didn't need to be on Mountain Lion, Lion, Snow Leopard etc etc - well not on any machines I have.  Maybe I got lucky, but I'd really like to understand the underlying use of the group staff that makes this necessary.