How Many Users Can You Create on macOS?

I have wondered from time to time about how many users you can create on macOS. It seems like a theoretical question, because why would you need more than a few users? When a customer with a lab needs to create local users when they first authenticate, they use products like our XCreds. But how many is too many? Should there be a limit and when should unused user accounts be removed?

Initial login can take about 35 seconds when you first create a user, subsequent logins are much faster (typically less than 5 seconds). It seems like it would make it beneficial to pre-create lots of accounts on a Mac right from the beginning to improve login times without the 35-second wait caused by having to create the account. 

But this brought me back to my initial question—is there an upper limit to how many users you can create on macOS? What is the limiting factor, if any? Disk space? 32-bit UIDs? 

I set off to find out.

XCreds is a login window replacement on macOS and can create new users on the fly, making it a great tool for my purposes. My approach was to automate XCreds to continuously create new users and see when it all went sideways on the Mac.

I modified XCreds to automatically create a new user with a generated UUID as the username and password and then log in. The account is then created, along with the home directory. This worked perfectly for the first account. However, I then needed a way to log out to start the whole process over again. 

Ironically, automatically logging out of a newly created account turns out to be a bit tricky. 

I could use Apple Events, but then it prompts to allow it to happen, making the automation part of the approach moot. It turns out that you can use launchctl to shut down all the GUI processed and log out the user. For example, if the user has a UID 501, the user can be logged out using:

launchctl bootout gui/501

It has to be run as root and I needed to figure out who is the user currently logging in. Those are straight forward. First, I created a launch agent that runs as the user at every log in:

#!/bin/sh

# Save the date in a file called timestamp.txt
# each time it runs so we can see how long it
# took and also how many times.
date >> /Users/Shared/timestamp.txt

# Create a file to let the launch daemon running
# as root to actually do the log out.

touch /Users/Shared/logout
I then created a launch daemon that triggers on the touched file and logs the user out:
#!/bin/sh

# verify the file exists, and if it does, remove.
if [ -e /Users/Shared/logout ]; then
   rm /Users/Shared/logout
fi

# log the user out

I then set the script to run as root when the file appears. This is the launch daemon script to watch the file created above and run the script to log the user out.

#!/bin/sh

if [ -e /Users/Shared/logout ]; then
   rm /Users/Shared/logout
fi

I then set the script to run as root when the file appears:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.twocanoes.logout</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Users/Shared/logout_current_user.sh</string>
    </array>
    <key>WatchPaths</key>
    <array>
        <string>/Users/Shared/logout</string>
    </array>
</dict>
</plist>

With my script ready to go, I rebooted the Mac. It logged in, created the account and home folder, then logged out. The process then automatically repeated. Creating the new account took about 29 to 35 seconds per iteration. I left it to run and everything seemed to be working swimmingly:

Thu Aug 14 09:39:44 PDT 2025
Thu Aug 14 09:40:06 PDT 2025
Thu Aug 14 09:40:29 PDT 2025
Thu Aug 14 09:40:53 PDT 2025
Thu Aug 14 09:41:15 PDT 2025
Thu Aug 14 09:41:40 PDT 2025
Thu Aug 14 09:42:05 PDT 2025
Thu Aug 14 09:42:33 PDT 2025
Thu Aug 14 09:43:00 PDT 2025
Thu Aug 14 09:43:27 PDT 2025
Thu Aug 14 09:43:52 PDT 2025
Thu Aug 14 09:44:16 PDT 2025
Thu Aug 14 09:44:43 PDT 2025
Thu Aug 14 09:45:08 PDT 2025

Home Directories were getting created:

Then, it failed at around 200 users.

What had gone wrong? I ran out of disk space. Awesome! Now I had a side quest to figure out where all the disk space went.

Side Quest: What is in a new macOS home directory?

For my initial testing I was running in a virtual machine and had allocated 80 GB for disk space, which seemed like plenty since every home directory should be empty. It turns out that “empty” means about 180 MB:

Size	Folder
0B	Desktop
0B	Documents
0B	Downloads
0B	Movies
0B	Music
0B	Public
133M	Library
3.2M	Picture

I was a bit surprised to see 133 MB for the Library folder. A quick peek into the details and it turned out that the used up space was mostly in /Library/Caches, and the GeoServices folder in Caches was very large:

Size	Item
35M	GeoServices
1.3M	GeoServices/Default_Icons-29442.icondatapack
1.4M	GeoServices/streaks_hz-1.png
2.5M	GeoServices/Guides_Icons_Default-366.icondatapack
3.1M	GeoServices/Default_Icons-29471.iconconfigpack
3.2M	GeoServices/Default_Icons-17710@2x.iconconfigpack
3.3M	GeoServices/Default_Icons-17678@2x.icondatapack
4.8M	GeoServices/territories-2.tbz
6.3M	GeoServices/Guides_Icons_Default-363@2x.icondatapack

What, you ask, was in those all those files? Lots and lots of icondatapack, which are images used for maps:

https://theapplewiki.com/wiki/Apple_Maps_icons

So that mystery was solved. Home folders are large because of cached map icons (and other cached icons).

Now, I have no idea why they need to be there in every new folder, but at least the mystery was solved, right?

Mini Quest

As I talked about what I’d discovered on the Mastodon, I was asked if the files were actually using disk space or were using APFS “Copy on Write”:

So another side quest. Since I was already on a side quest, this is a mini quest inside of the side quest.

How to find if APFS Copy on Write is actually used for new home folder creation

Copy on Write is a feature of APFS that saves disk space and speeds up performance. When a file is copied, a file system reference is made to it, and the actual data is not copied. When the file system gets a request to actually modify the file, the file is then copied and the changes are made. Since most copied files don’t get modified, this results in less space used and instant copy times. Newly created home directory caches may use it, but I wasn’t sure how to check to be sure. 

I had no idea. So I asked around for an easy answer and got: “look at the total space used.” So I opened up Disk Utility on a Mac where the home directories had been created and discovered that about 40 GB had been used for the 200 home folders. But was this “actual space used” or “potentially disk space used if copy-on-write”?

This led to a large discussion of IO registry entries, how file systems work, and a neat command line tool I had no idea existed:

APFS.UTIL(8)                                                                                                                           

NAME
     apfs.util – APFS file system utility

DESCRIPTION
     The apfs.util command supports getting and setting various file system options.

Using the -G option, you can see “purgable space”:

mdscentral:~ tperfitt$ /System/Library/Filesystems/apfs.fs/Contents/Resources/apfs.util -G /System/Volumes/Data
Getting purgeable file stats on /System/Volumes/Data returned 0 (Operation not permitted)

Total num purgeable files: 4546   Total purgeable data size: 45371772928
   type     Photos: num purgeable files:   2084 purgeable data size:  402792448
   type  Documents: num purgeable files:    203 purgeable data size:  209145856
   type       Data: num purgeable files:   1439 purgeable data size: 44344066048
   type    Podcast: num purgeable files:    355 purgeable data size:  101289984
   type   Messages: num purgeable files:    465 purgeable data size:  314478592

You can also use apfs.util to purge space with the -P option. This led to a discussion on CoreServices APIs and tangentally related Wikipedia articles. Shaking my head to clear it, I emerged from the rabbit hole.

So the answer to “How to find if APFS Copy on Write is actually used for new folder creation?” is…maybe? It’s a hard question to answer, and finding out for sure will have to wait for a future investigation and potentially another post. But what we do know is that the home directory space is almost certainly actual disk space used. 

Home Folders use more than expected disk space because of cache icons. Time to move on.

Back to the Main Quest

I moved the entire setup to a physical Mac (M3 iMac running macOS 15.6) and let it run overnight. When I returned in the morning, the Mac had gone to sleep. Since new user creation took so long, the Mac got bored and went to sleep. Which was fine, since creating 1000 users and slow login seemed to hold the answer I was looking for.

Looking at the log file, when around 400 accounts are created, account creation time starts to go up from 35 seconds to over 100 seconds for 1,000 user accounts:

The spikes are from macOS running too many processes and rebooting. The processes for indexing spotlight per user seemed to continue after logout and could only be killed using “kill -9”. These built up until they caused a reboot. I investigated ways to resolve this but ultimately decided that the Mac panicking and rebooting seemed to work just as well.

The user creation time stays between 29 and 35 seconds until about 400 users and then climbs linearly to 100 seconds at 1000 users. Waiting over a minute and a half to log in is a long time, but I was curious how long subsequent logins took.

I logged in as the first user I created, and it took less than 5 seconds to get to the desktop. Logging out took 45 seconds. Looking at CPU usage, opendirerectoryd was pegged:

The next login as the same user was fast as well (about 5 seconds) and logout was again 45 seconds. 

I then tried to log in as a different user. The login screen was still showing user icons, and that seems to be responsive even with 1000 users:

However, selecting a user resulted in a spinning wheel for multiple minutes and an eventual kernel panic and reboot. After reboot, I logged in as the first user again and tried to open Users & Groups in System Settings. It froze up the interface and eventually the user session crashed and was logged out. When logging in again with the same account, the Mac restarted.

Here is what logging into a Mac with 1000 users looks like.

Results

I think I got the answer to the “How many users can you reasonably create on macOS?”

About 200 Users

The Mac system has issues with 1,000 users and user creation times increase at about 400 users. 

I didn’t do any tests with users with secure tokens, but I have heard from others that going above 250 users may cause issues. 

If you have a multiple-use Mac (like a lab machine or a kiosk), keep the number of local user accounts less than 200 users, and the login times, disk space, and stability should be fine.

---