Skip to content. | Skip to navigation

Personal tools


You are here: Home / Notes / Change a user's User ID on Mac OS X (10.6, 10.7, 10.8, 10.9, 10.10, 10,11)

Change a user's User ID on Mac OS X (10.6, 10.7, 10.8, 10.9, 10.10, 10,11)

Posted by Roman | | filed under:
How to change a user's ID on Mac OS X Version 10.6 and above (10.6 "Snow Leopard", 10.7 "Lion", 10.8 "Mountain Lion", 10.9 "Mavericks", 10.10 "Yosemite" and 10.11 "El Capitan")

I always wondered why I couldn't write and create folders (which is also, in fact, a write operation from the unix point of view) on my other Mac's AFP share. Finder always complained about insufficient rights - even when I was trying to write to the user's own home folder on the other Mac!

Ok, maybe it was too obvious: My users had the same name but different user IDs. I wouldn't have been surprised when that would've happened on my linux or BSD boxes - but with Apple products? No way, I thought. But I was wrong.

Now, my problem was: I couldn't imagine that it's possible to change the user ID (uid or UniqueID in Apple's terms) without any problems - taking into account that Mac OS X is still something like a heavily customized BSD (ok, no ranting here please, I know the differences). So, after some googling I found an article on [the page seems to have changed since I wrote this guide] which covered changing the uid on Leopard. While most of the information is still true with Snow Leopard, the process (and some of the commands used) should be modified slightly.

There may be a problem with this procedure when FileVault 2 full disk encryption is enabled (according to javadoug's comment below). Be sure you have a proper backup and a second user you can log in with before changing the UID.

Ok, let's get going:

0. Prequisites

First of all, don't do this while you are logged in as the user whose uid you want to change. Seriously, don't do that.

The imho best way is to use "sudo". With sudo you have (at least) two options:

  1. You could prefix "sudo" to each of the commands given below (but read the comments below as you will have some problems).
  2. And you can – preferably – temporarily turn your shell into a "root shell" (which you have to do only once):
    mybox:~ mydir$ sudo -s

    (For some more information regarding sudo read the sudo man page (sudo man) and the comments.)

(Another clean way of doing this is as the root user. To work as root user, you have to enable the root user on your Mac OS X first. Afterwards, log in as root as decribed in Apple's article.)

1. Change UID

Read the uid (given Alice as the user's name, 501 as old and 1234 as the new uid):

# dscl . -read /Users/Alice UniqueID
UniqueID: 501 

Change uid:

# dscl . -change /Users/Alice UniqueID 501 1234

Verify that the uid has changed:

# dscl . -read /Users/Alice UniqueID
UniqueID: 1234

2. Change ownership of the user's files

As noted in the article I referred to earlier, the ownership of the user's files has to be changed on every filesystem the user had written to. So do (at least) the following (updated, thanks pir, Tomás & Creeture):

# find /Users/Alice -user 501 -print0 | xargs -0 chown -h 1234
# find /Library -user 501 -print0 | xargs -0 chown -h 1234
# find /Applications -user 501 -print0 | xargs -0 chown -h 1234
# find /usr -user 501 -print0 | xargs -0 chown -h 1234
# find /private/var/ -user 501 -print0 | xargs -0 chown -h 1234

If you want to be sure that you changed the ownership of all files of the root partition ("Macintosh HD" or whatever you named it), you could do the following (but be prepared that this takes considerably longer, especially if you have much data in /Users):

# find -xP / -user 501 -print0 | xargs -0 chown -h 1234

A simple test if there are files left that are owned by the old uid:

# find -xP / -user 501 -ls

Remember that you have to check the ownership of files on every filesystem that the user had written to.

3. Rename special files and folders

But that was not all. Mac OS X has some special files and folders that have the (old) uid as part of their names. These include (on my Mac, ymmv):

  • /.Trashes/501
  • /Library/Caches/
  • /Library/Caches/
  • /private/var/db/launchd.db/
  • and possibly some files in /private/var/folders/ud/(some ugly dir name)/-Caches-/

For every of the above you have to do something like (you may have a look at Guido's tip below - thanks Guido! -, but I haven't tested that and my Bash skills are inferior, apparently ;):

# mv /.Trashes/501 /.Trashes/1234

Finder creates folders like these on every (local) filesystem you move things to Trash from. Therefore, you have to check every filesystem for the existence of a folder named .Trashes/501 like, for example, /Volumes/My External Disk/.Trashes/501. If you don't do this, you may possibly end up in wasted space (but I haven't checked this).

If you want to check if there are remaining files or directories that have the old uid in their name, you can, again, use find (thanks Tim!):

# find -xL / -name "*501"

4. Finalize: reboot

As Thomas stated below, it's wise to reboot your machine after this procedure (you're absolutely right Thomas). Otherwise strange things happen if you try to log in with the changed user id.

Further information

For further information please consult the original article I took this information from.

Update 2014-07-22

This is still working on 10.9 "Mavericks", so I updated the article to reflect this.

Update 2015-03-12

I recently used this procedure on OS X 10.10 Yosemite. Worked as expected.

Filed under:
Anonymous says:
Jan 20, 2011 06:46 AM
Thanks so much for this guide! It's exactly what I was looking for to resolve the Microsoft Office UID save to server bug.

Just a quick note that I found a bunch of files inside /private/var/ that also needed to be chowned.

Thanks again!
Anonymous says:
Feb 02, 2011 08:10 PM
I'm glad it helped.

You are absolutely right, Aaron. I've missed that in the first place but the files and folders in /private/var (including the aforementioned launchd directory, of course) have to be chowned, too. I've updated the guide.

Thanks for your hint!
Anonymous says:
Jan 26, 2011 12:56 AM
I used sudo rather than root for this process.

I was able to find remaining files/directories by using:

  sudo find -xL / -name "*501"

where 501 was the old uid (in fact I did *501* initially, but a scan of filenames output showed that the 501 was either at the end, or well embedded in the filename).

With sudo, it appeared impossible to enter some directories where there was a file needing renaming. In this case, do a "sudo mv" but you'll have to put the directory name in as well. That seemed to work.

In the case of launchd.peruser.501, the filename *and* the directory it's in need renaming.

Finally, make sure you do the "sudo find" I listed above as a final step, to be sure you have changed all files/directories.

A useful guide - thanks!
Anonymous says:
Feb 02, 2011 08:12 PM
Personally, as an old Linux guy I prefer working as root. But for this guide I think it's best to use the root user over the sudo approach because using sudo implies that you work as a different (non-privileged) user (what may but doesn't necessarily have to be the case). Using the root user, you don't run into the mentioned problems entering folders that you don't have access to. In the end, using sudo or the root user is mostly just a matter of preference.

In fact, while writing this guide (and solving my own problem, that is), initially I had searched for files and folders containing 501 anywhere in theirs names (the *501* thing), too. It turned out that there were too many files and folders which carried 501 in their names without being related to the uid anyhow but only a few to none (I don't remember) relevant ones that should have been renamed. So I did it exactly as you suggest.

I've updated the how-to accordingly. Thanks for your hint, Tim!
Anonymous says:
Feb 02, 2011 08:47 PM
Great discussion guys. I didn't mention it earlier, but I used sudo for this entire process as well.

I don't like to keep root enabled on my client's machines, and I find it's generally faster to sudo than toggling root access on and off.

Also, with sudo, there's no chance I'll forget to disable root when I'm done.

I think Roman's exactly correct. It's usually a matter of personal preference.

Anonymous says:
Feb 03, 2011 02:16 AM
Yet another sudo discussion? ;)

Don't get me wrong, sudo is a great tool and I use it frequently, too. But sometimes I tend to use the root account, especially when I have to use lots of admin commands - or write some how-to that should be easy to use.

Another option, of course, is to use "sudo -s" or "sudo -i". This will turn your shell into a "root shell" so you don't need to enable the root user or hack in "sudo" again and again (which can be quite annoying).
Anonymous says:
May 04, 2011 12:24 AM
What modifications are needed for 10.4.11. I have tested the above info in Snow, however I have a few users in 10.4.x
Anonymous says:
May 04, 2011 12:26 AM
I'm sorry but I can't test that because I don't have a machine running Tiger any more.
Anonymous says:
Sep 02, 2011 03:27 PM
very helpful
Anonymous says:
Sep 02, 2011 03:28 PM
Excellent article, thanks! I just used this on 10.7 Lion and it works perfectly.
Anonymous says:
Sep 02, 2011 03:28 PM
Just wanted to say thanks! The procedure worked just as described. The only thing I'd add is to reboot after all the chown-ing and mv-ing is done. I logged into one of the affected accounts immediately after moving everything around and everything was wonky (no Desktop, no Finder, etc). I'm guessing some processes got confused by the changed UIDs and needed a fresh start.
Anonymous says:
Sep 02, 2011 03:28 PM
   Hello to all,

   In '2. Change ownership of the user's files', I think than it should be better do:

   # find -x / -user 501 -exec chown -h 1234 {} \;


   # find -x / -user 501 -ls

   With this you change all your symbolic links too.

Anonymous says:
Sep 02, 2011 03:28 PM
Thanks for this, very handy.

One thing to add is the chown call should be chown -h or if you have any symlinks then they end up beloning to the old userid.

I also changed the gid (PrimaryGroupID) to match and did the same thing for the chgrp call.
Anonymous says:
Oct 31, 2011 01:30 AM
For some reason, chown wasn't in my path and couldn't find it since the locatedb wasn't properly loaded. Took me a while to find it but wanted to make sure others could find it easily.

It's in /usr/sbin/chown

Thanks again for this guide! Adding it to delicious now!
Anonymous says:
Nov 03, 2011 08:43 PM
Hi all,
Anyone can help me with this ?

acid-macbook:~ root# dscl . -change /Users/raph/ UniqueID 502 1000
change: Invalid Path
<dscl_cmd> DS Error: -14009 (eDSUnknownNodeName)


Anonymous says:
Nov 18, 2011 02:52 AM
dscl needs for you to drop the / after raph.
dscl . -change /Users/raph UniqueID 502 1000
Anonymous says:
Nov 18, 2011 02:52 AM
In Bash, instead of:

 mv /.Trashes/501 /.Trashes/1234

you can do:

mv /.Trashes/501 !#$:s/501/1234

Can be handy if you have to do lots of renames.
Anonymous says:
Nov 18, 2011 02:52 AM
This one might be a little more complete. Also changes owner of symbolic links. That might be important when $uid doesn't own the parent directory that contains the symlink or other scenarios. Also uses xargs to execute the chown command as few times as possible. Note I just did this on Lion.

find -xP / -user 501 -print0 | xargs -0 chown -h 1000
Roman says:
May 23, 2013 06:46 PM
Finally, I've updated the guide according to your hint. Thank you!
Anonymous says:
Jan 04, 2012 04:10 PM
It's very important to use "chown -h" instead of "chown". chown without -h change the link target. The link target may have a completely different uid.

Suppose you have a symbolic link created in /Users/Alice/mylink ->/

chown 1234 /Users/Alice/mylink

will change the owner of / and not of mylink!!
Roman says:
May 23, 2013 06:46 PM
Right, I've changed the commands. Thank you!
Anonymous says:
Jan 21, 2012 06:18 PM
Hi there,

is it not enough to open the Apple System Preferences/Users and right-click a user and change the user-id right there? After a restart it also changed automatically the ownership of the user's files? Or would this only change the user-id and nothing more?

Thanks for any hints …
Anonymous says:
Jan 21, 2012 06:23 PM
I doubt that this will work, but I haven't checked. Feel free to try and report back :)
Anonymous says:
Feb 11, 2012 09:36 AM
No, it's not sufficient. This only changes the user ID, but not any file ownership IIRC.
Anonymous says:
Oct 03, 2012 02:25 AM
... (with the help of the System Preferences) on a lot of machines without any problems, maybe Apple fixed the behavior? No problems here, but of course you should have an 1:1 clone or a backup of your system and user stuff.
Anonymous says:
Jan 21, 2012 06:19 PM

This is a great manual!

I've recently added an SSD to my system, installed SL there and _then_ migrated my main user from the old HDD to the new one. So far, everything was fine, but I couldn't move/rename/... files belonging to the user (with the same name) on the old disk.
Since I wanted to have my System and Accounts on the SSD, but the working files ("data") on the old drive, this was a real pain. I didn't want to get rid of all user stuff on the old drive either, to have a fallback in case there were issues with the new SSD.

I tried changing permissions via the cmd+I possibilities, repaired permissions, etc. All in vain, since my user was already the owner with r/w access, judging by the _name_

After quite some searching, I figured that they had different UIDs (old: 501 and new: 503), which -despite the matching account names- kept the new user from accessing the files from the old one.

So, I followed your steps here and changed the UID from my new (SSD) user to match the UID of the old one, which went well. Logging back into the main user, I found the files of the old user left with a "_unknown" owner.
I find this strange because as 503, I was not allowed to move/rename them and now it appeared as the (removed) 503 user was missing.
Anyways, I fixed that with the permissions section in the cmd+I windown and everything works fine.

I will now check whether I can still boot/login from the old HDD to see whether my fallback works.

At least for the main issues I'm now really happy. Thanks!
Anonymous says:
Apr 06, 2012 06:54 PM
I have done this on SL, but now find that the user wont show up in the login window. I can manually type in my user name in the login window and that works.

Anyone have an idea why this is?


Alexey says:
Aug 29, 2016 02:59 PM
I have experimentally discovered that the UID 1000 is somehow reserved by Mac OS: if i set UID to 1000, then i will not see the user in the login window menu. There is no such problem with UID 1001.
Anonymous says:
May 24, 2012 07:55 AM
Changing to the root user worked up until I got to the Directory Utility. from that point there was no option for "Enable Root User" from the Edit window. Please advise.
Anonymous says:
Jun 19, 2012 10:55 AM
No problem at all - just use the sudo method (In Terminal, type 'sudo -s' once, then begin with the rest of the guide. Be sure to use a different user account - not the one you want to change.)
Anonymous says:
May 24, 2012 07:55 AM
You explained exactly what I was looking for.
Works great under Lion.

Anonymous says:
May 30, 2012 06:55 PM
Thank you all for your useful comments! I've updated the guide accordingly.

I'm glad if this how-to is helpful.

Anonymous says:
Sep 01, 2012 11:46 AM
This is a great walk through and has worked flawlessly a few times now. I was wondering if you think this would easily be implemented in a script with prompts to enter text (username, mainly).

I'll be working on it regardless, but my skills aren't that fantastic.
Anonymous says:
Sep 01, 2012 12:08 PM
Glad to hear!

Sure, writing a script for this shouldn't be much of a problem. But I'm currently extremely busy, so I'm afraid I can't help you with that atm.

Anonymous says:
Aug 23, 2012 07:03 PM
First of all this article is great! Everything worked flawless for me. I am also interested in changing the default GID for a user account. Can this same process be applied to change the GID? I tried using GroupID instead of UniqueID in your commands but that didn't work.

I haven't found a list of 'keys' that would apply here, but I haven't looked that far into Google either. I just thought I would start here since this is already a great article!

Thanks in advance for your help!
Roman says:
May 23, 2013 07:06 PM
Glad to hear, thanks! :)

To change the default GID for a user account, you have to change the "PrimaryGroupID" (as pir stated above). Just have a look at the output of "dscl . -read /Users/Alice" (given Alice as the user name); the PrimaryGroupID is the numerical ID of the account's primary group.

The procedure is exactly the same as above, except that you have to use PrimaryGroupID instead of UniqueID and chgrp instead of chown.
Anonymous says:
Nov 12, 2012 07:28 AM
I'm trying to chown as root on Mac OS 10.8 and it's saying operation not permitted. I thought root could do everything? Any ideas?

I'm a UNIX guy, not Mac, so any pointers would be appreciated.

Anonymous says:
Nov 12, 2012 07:28 AM
find /private/var/ -user 501 exec chown -h 1234 {} \;
is missing the "-" in front of exec

Otherwise a great help, thank you!

One thing that puzzles me is how MacOS can have multiple owners and groups in the Info window...
Roman says:
May 23, 2013 06:43 PM
Fixed. Thanks for your hint!
Anonymous says:
Dec 03, 2012 05:24 PM
Hi - many thanks for this, very useful.

I got a few errors during the chown operations - "chown: /Users/blah/blah.blah: Operation not permitted" on some locked files.

I got round this my making a little batch file up to do:

    chflags nouchg "/Users/blah/blah.blah"
    chown -h 1234 "/Users/blah/blah.blah"
    chflags uchg "/Users/blah/blah.blah"

There's probably a one liner for it, but that worked for me.
Bob says:
Sep 20, 2013 08:04 AM
I think the "chown -h 1234 ..." command might instead be "chown -hf 1234 ..." - this gets around the case where some files won't allow changes due to extended ACL's and other possible issues. Same goes for Jamie too I think.
Anonymous says:
Dec 03, 2012 05:24 PM
Hi there, just thank all you, this worked great!
Had reinstalled my macbook and forgot to create a first user to match ID with my remote timeMachine backup.
I followed the process and changed UID successfully and all worked again, also backup to my old backup-copy.
Anonymous says:
Jan 12, 2013 01:43 PM
After following this good guide I am missing the user in the list of available users in the login screen. I still can login by pressing login as a different user and entering the login and password. I am still looking around to find a solution for this. Any tips?

Anonymous says:
Jan 19, 2013 03:22 AM
I'm (still) running 10.5.8. I followed the above how to and everything seems to be working fine except for one thing. The 'Documents' folder in 'Places' under my username is not accessible, says I don't have the appropriate priveleges. When I 'Get Info' on this folder it shows an unknown user as the owner. I'm guessing I need to make that me. I ran the #find -xL / user 1000 -ls command to see permissions for the new 1000 UID that I created (to match Linux Ubuntu UID) and can't see anything immediately wrong, although I am not a Unix expert it seems I own and have permissions for 'Documents' under /User/csh (csh is the short name that corresponds to the UID 1000.) By the way to get to this point, rather than run the multiple exec chowns I followed Creeture's xargs method and that seemed to work - all but this particular issue. Also note that I can access all my files. There are no files in the inaccessible 'Documents' folder and there is another 'Documents' folder directly under the Mac Harddrive - I am not a regular Mac user but would like to change that. I was thinking to try this although not directly related it sounds like a similar issue and figured it can't hurt but my CD drive is broken. I also tried running this command in a terminal and again as root user: sudo chown -R csh /users/csh/Documents and then 'sudo chown -R u+rwX /users/csh/Documents' but I get 'Operation not permitted' for both of these. Finally, as per Mike, the user doesn't appear in the list but can be accessed by manually typing in the credentials from the 'Other' option.
Cabeleireiro says:
Jun 18, 2013 06:05 PM
interestingly, I didn’t get the permissions error when I inlslated this on a second instance of Ubuntu. So the permissions error probably had something to do with the state of that instance of Ubuntu. I had been experimenting with putting my home folder on a second hard drive. Not sure how that could have messed up permissions to the /usr/lib folder, but at any rate on a fresh install I didn’t get the permissions problems…
Ed Burns
Ed Burns says:
Jun 27, 2013 03:13 PM
I was looking for a way to change the GID of an existing group in Mountain Lion 10.8. I didn't see anything about after some quick web searching, so I thought I'd just add on here after figuring it out.

In System Preferences, select "Users & Groups". Select the desired existing group in the left pane. Ctrl click on the desired group and choose "Advanced Options...". You will be presented with a modal dialog in which you can edit the GID.
javadoug says:
Sep 02, 2013 05:41 PM
Make sure you have a back up!!! These steps failed for me. After following described steps, I could not login with my modified user. I booted into recovery mode and repaired permissions and verified the disk. I also used resetpassword to update the users home folder ACLs. I reset the user password for good measure, too. All to no avail.

One possible difference is my HD is encrypted. I'm not sure if that is the reason or not but I now need to restore from back up.
Roman says:
Sep 02, 2013 09:14 PM
Sorry to hear. I never tested changing UIDs with File Vault 2 enabled.
Roman says:
Sep 02, 2013 09:26 PM
Maybe this has something to do with the GeneratedUID problems (see[…]/)?
Bob g
Bob g says:
Sep 02, 2013 11:52 PM
To be consistent to convert to UID 1234, I think your code sample in the original posting:

# find -xP / -user 501 -print0 | xargs -0 chown -h 1000

Should be:

# find -xP / -user 501 -print0 | xargs -0 chown -h 1234
Roman says:
Sep 03, 2013 10:16 AM
Thanks Bob, I missed that.
javadoug says:
Sep 03, 2013 01:12 AM
Thanks, Roman. The generated uid issue seems more to do with network login. I think I have a solution which did not require restoring from back-up.

Here was my problem:
After following the described steps as outlined in your article, I could not login. The login screen showed me two prompts one for the user and one for the hard disk. Logging in to either one would just freeze.

Couple things to note: My HD was encrypted and the user was enabled to login without prompting for the HD pwd. And my file system had uid issues but didn't manifest themselves until after encrypting the HD. A long time ago I had to create a new user to fix some other stupid apple issue. Hence my user had uid 502 but a lot of files on the disk were owned by 501. After encrypting the drive (and a lot of pain doing that, too, see: now all the 501 stuff was not accessible. So I decided to use your very well done steps to solve my problem of getting all the files under the original user uid 501.

To be fair: I don't think your steps had anything to do necessarily with the issues I'm having. I suspect my mac was not in a good state even though it was working.

Here was the solution:
In addition to all the steps in your article, I did these additional steps to get back to working with no uid 502 files.

1. boot into recovery mode.
2. unlock volume (my HD is encrypted and pwd protected).
3. ran repair permissions and repair disk.
4. reset user's folder ACLs using resetpassword (I did this for all the users, myuser, macports and root).
5. rebooted and logged in as myuser to see if it solved the problem (optimistic that it should!).
But it didn't, so I continued.
6. boot into recovery mode again.
7. reinstalled OS X.
After this completed successfully, I still had issues logging in with myuser.
8. boot into recovery mode again and unlocked my drive.
9. ran repair permissions and repair disk and reset my user's ACLs.
Rebooted and logged in as myuser. I don't remember if it worked right off the bat or if I attempted to login more than once but now I'm able to login with myuser.

Now when I run sudo find -xP / -user 502 I get no files found! And it seems like all my data is there. My ruby development environment no longer works. I need to install xCode, it seems that got lost in this process. It's like I have a clean machine. I thought all my development stuff would still work but I guess not.

Anyway, Roman, I think I'm back on track. And thank you for your article it did help me.

For other readers, the alternative approach I think might have been cleaner: just create a new user and migrate the user data from time machine back-up rather than mucking around with all these low level commands. However, I do have a lot more understanding of how the ACLs work!
MattT says:
Sep 12, 2013 03:54 AM
Hey, Thanks for the info, very helpful with some work I'm currently doing.
Just though that I'd add a way to find what user is currently 501 as that is (in my case) a required step:

dscl . -list /Users UniqueID | grep 501 | sed 's/ 501//g'

In short, list all users and UniqueID | get the line with the 501 | remove the spaces and the 501
you can then use the output of this to assign to a variable such as $USERNAME to then use
`dscl . -read /Users/$USERNAME`
or in-line
dscl . -read /Users/`dscl . -list /Users UniqueID | grep 501 | sed 's/ 501//g'`
which will produce the same result says:
Sep 18, 2013 11:13 AM
The whole discussion is way over my head! I just want to create a new username and since my machine is in a secure location, I want to log on once each day, shut down and start up and log on the next day (or so) without having Lion prompt to log on every 10 minutes. A simple answer please even if means having reload my whole system!.
Bob says:
Sep 20, 2013 08:09 AM
This is a really great set of notes on how to get something done that was very difficult. Thanks so much - and you might want to update the "chown" commands to include the "-hf" instead of "-h" switch to get around the possible problems with extended ACL's that can prevent chown from working correctly.

Now if only I could figure out why Migration Assistant gets an error when I try moving over one particular user. It copies the files OK, but gets an error when creating the user, so doesn't complete the migration process completely.
Wolfgang says:
Nov 21, 2013 09:07 AM
Do not forget the dropbox stuff in /Library/DropboxHelperTools/
AnneTheAgile says:
Feb 02, 2014 08:59 PM
Explaining Guido's hint; here is a how to, demonstrating how we can avoid use of Sed and yet also use and replace a prior argument! Thank you to both Guido and Roman especially for hosting this page.
$ pico
$ chmod a+x
$ cat ./
echo "arg1=$1"
echo "arg2=$2"
$ ./ one two
$ ./ hi !#$:s/hi/bye
./ hi bye

AnneTheAgile says:
Feb 02, 2014 09:00 PM
HowTo: Use Bash Parameter Substitution Like A Pro - nixCraft
ESC-_ or !$: repeats the last argument of the previous command.
AnneTheAgile says:
Feb 02, 2014 09:21 PM
Finally, this tutorial also works for 10.5 Leopard, better than the cited one because niutil is not present on 10.5, only dscl.
#443 (niutil and nidump are no longer existant in 10.5 leopard, so you should use dscl instead) – Tor Bug Tracker & Wiki
revher says:
Mar 05, 2014 09:20 AM
Thank you for this tutorial. I am still hesitating because of a lot of installed programs like TimeCapsule, Iphone sync and backup, Xcode etc. My initial need was to be able to mount my OS/X remote partition from a Linux box, using "sshfs host: mountpoint". If id are different, mapping is needed.

But looking at the different steps proposed, I suggest some variants or additions which could be useful:
- At first there is an Apple tool which you can install. Google for "Server Admin Tools 10.7" or whatever version. The tools will be installed on /Applications/Server and from there you can use the Workgroup Manager. It can be helpful to look at your user id and group id, create new groups etc. It is a server application but it works for clients. It is a GUI for the dscl command which is probably better, but sometimes I got errors in changing my main GroupID and these errors disappeared using Workgroup Manager. Here are a few suggestions:
- "id Alice" is a standard Unix command which also gives the various groups the user belongs to. It reveals if admin (80) belongs to it or not.
- For example, it is important to be aware that some applications belongs to the user but also the group admin. They can be fetched by the command:
 find /Applications -user 501 -group admin -ls
and changed (with other Application with id 501 and either admin or staff gid):
 find /Applications -user 501 -exec chown -h 1234 {} \;
The above command is, in my view, similar but quicker to:
 find /Applications -user 501 -print0 | xargs -0 chown -h 1234
Also for finding the directories and file including ".501" in their name, I use:
 find /private/var/folders -type d -regex ".*\\.501.*"
for directories (in a first step) and
 find /private/var/folders -type f -regex ".*\\.501.*"
for standard files. Then you have to rename the files with mv.
Josh says:
Aug 07, 2014 09:32 PM
These steps worked great for me on OS X 10.9.4 with FileVault (whole disk encryption) enabled. Thanks!
Joe says:
Nov 18, 2014 09:52 AM
Thanks for this guide. It's definitely what I need to share my home folder with Linux. But what about Time Machine backups?
As long as I can see all the files in Time Machine have the original user (and group) ID.
Is it safe to change the IDs of the backup files using find?
Roman says:
Nov 26, 2014 08:31 AM
Glad if it helped.

About the Time Machine backups: Yes, it should be perfectly safe to change the ownership of the backup files.
osbjmg says:
Dec 03, 2014 04:27 PM
This was very helpful after migrating from HDD to SSD, spotlight and a few applications kept my older user ID.
Trudge says:
Jan 19, 2015 11:26 PM
Excellent guide to OSX 10.9.5 (Mavericks) groups and permissions. I run Perl through Apache and each script writes a log file to the current directory. But Perl runs as _www and I had to supply admin credentials each time I edited the log files. This guide went a long way to helping me clear up my situation. Many thanks.
Michael says:
Mar 26, 2015 05:09 PM
Thank you very much, this was very helpful. Now I can mount and write my new nfs home :) I have an addition, I found some files of my old user in /Users/Common and in /private/tmp . Don't know if these are important enough to make it into the guide, though :-)
CY says:
May 06, 2015 03:56 AM
Do we really need to change the Trash/Cache files? I thought those if not present will be created by the system. The old ones just left in there. I will try to test it when I get a chance.
Roman says:
May 06, 2015 11:17 AM
I assume you are correct and the cache and Trash files/folders will be (re-)created when needed. But the point is that the old files and folders will still exist and won't be purged (deleted) later – neither automatically nor as a result of a usual user interaction (emptying Trash), as there is no user left with a corresponding id.

Therefore, leaving these untouched will result in stale files/folders that may contain gigabytes of data (in the Trash, for example). Data that eats up hard drive / SSD space and, under normal circumstances, won't even be visible to the user.

Plus, if another user will be created later on that matches the old user id, I suppose that the new user will see and have access to the content of the cache and Trash of the old user. Maybe – I haven't checked – this data is somehow protected (by ACLs, for example), but I wouldn't assume that. This may, at the very least, lead to unexpected results.

To sum up, I would recommend renaming the cache and Trash files.
Rolf Meijer
Rolf Meijer says:
Dec 06, 2015 09:02 PM
There is an issue with vagrant too, boxes will not start when the creator uid is different from the one you’re running the box from. The uid can be changed in .vagrant\machines\default\virtualbox\creator_uid.
Chris says:
Dec 16, 2015 12:48 AM
These steps worked for me in El Capitan 10.11 Many thanks!
Christopher Karatzinis
Christopher Karatzinis says:
Mar 21, 2016 09:03 PM
Works perfectly with El Capitan. Great article
teee says:
Apr 11, 2016 03:05 AM
Hi Roman -- I too am grateful that you showed a path out of the afp mismatch morass. Does it work in El Capitan? I have OS 10.11.4 Any special caveats?
Thanks Teee
chuck says:
Aug 18, 2016 04:34 PM
Something I found that's somewhat related to this thread:

The following procedure will allow you to create a new user with your desired uid and not have to modify any files after the uid change:

1) Create the new user (System Preferences > Users & Groups).

2) Change the user-id in the GUI (RMB on the newly created user and select Advanced Options)

At this point, you would normally need to go in and change the appropriate files in Library, etc to be associated with this new uid. However, if you do the following, this step can be avoided:

3) Delete the newly created user (System Preferences > Users & Groups).

4) Create the new user again (System Preferences > Users & Groups).

This time, OS X (el capitan) will remember the uid you wanted and assign it to the new user by default, thus eliminating the need to go back and cleanup stale uid file associations.

Hope this helps.
Warner says:
Oct 08, 2016 12:51 AM
What about time machine? How does this interact with time machine volumes?
I remotely logged in, got a root shell with sudo su (yet another way :) and then did what was outlined here. There weren't many files with 501 embedded in the name (as opposed to appended), so the find for *501* produced a lot of false positives.

Otherwise, it worked great for me.
Add comment

You can add a comment by filling out the form below. Plain text formatting. Web and email addresses are transformed into clickable links. Comments are moderated.