263

I need to get rid of the pesky "Too many open files in system" limit on OS X 10.7.1. 

Is there a way?

7
  • 4
    Do you want to explain more about when this happens? In which circumstances?
    – slhck
    Jun 7, 2012 at 8:56
  • 1
    @slhck - I have the same problem. The circumstances are basically "at random." I'm a developer, so I'm using my Mac fairly heavily: running one or more databases, a web server, testing tools, one or more browsers, and a music player all at once. Google Chrome seems to be one program that has a lot of files open. Jun 22, 2012 at 18:25
  • 2
    Actually, my "heavy use" wasn't the issue; my settings for the maximum number of open files for the kernal and per-process were far lower than what the defaults should be. Jun 29, 2012 at 20:16
  • 3
    If your read Nathan's comment and wondered why he didn't include any details about the defaults, it's because he spelled it all out in his answer, below. (Nice answer! :)
    – Olie
    Jun 13, 2013 at 18:06
  • I'm in the same usage circumstance as Nathan Long, and found restarting Apache was the only step that "solved" the problem. I applied all the below limit increases but they didn't help immediately. I am running command line phpUnit tests > selenium server > firefox > apache > php > mysql all on the same macbook. Used to work fine until I upgraded to mavericks. The error I get is in the webapp being tested, i.e. it's php/apache running out of files, so presumably not controlled by the shell setting.
    – scipilot
    Sep 19, 2014 at 7:55

13 Answers 13

283

According to this helpful article (which I recommend reading):

By default, the maximum number of files that Mac OS X can open is set to 12,288 and the maximum number of files a given process can open is 10,240.

You can check these with:

  • sysctl kern.maxfiles
  • sysctl kern.maxfilesperproc

You can increase the limits (at your own risk) with:

  • sysctl -w kern.maxfiles=20480 (or whatever number you choose)
  • sysctl -w kern.maxfilesperproc=18000 (or whatever number you choose)

To make the change permanent, use sudo to put your settings in /etc/sysctl.conf (which you may have to create), like this:

kern.maxfiles=20480
kern.maxfilesperproc=18000

Note: In OS X 10.10 or lower, you can add setting in /etc/launchd.conf like limit maxfiles and it will override whatever you put here.

Again, from the article:

Once you’ve done this, the kernel itself will have a maximum number of files but the shell might not. And since most processes that will take up this many files are going to be initiated by the shell you’re gonna want to increase that.

The command for that is:

ulimit -S -n 2048 # or whatever number you choose

That change is also temporary; it only lasts for the current shell session. You can add it to your shell configuration file (.bashrc, .zshrc or whatever) if you want it to run every time you open a shell.

13
  • 1
    what limit applies to processes launched by clicking icons in the launch area? And how to change that limit? When you say "shell", I'm assuming you mean an interactive terminal shell.
    – Cheeso
    Aug 15, 2012 at 0:48
  • 1
    creating an /etc/launchd.conf with contents limit maxfiles 1000000 1000000 worked great for me! (OSX 10.8.2 here) Feb 1, 2013 at 19:26
  • 1
    I put kern.maxfiles=65000 kern.maxfilesperproc=65000 in /etc/sysctl.conf and rebooted. kern.maxfiles was ignored and stayed the default but kern.maxfilesperproc was set to 65000. I have no /etc/launchd.conf so what's up with that?
    – pferrel
    Nov 13, 2014 at 0:47
  • 1
    I come here to find this post at least once every 6 months or so! Awesome ;) Jul 28, 2016 at 1:46
  • 3
    If anyone has problems with max files not sticking, it is because there is a trailing space after the maxfiles line, that needs to be deleted.
    – jjathman
    Oct 14, 2016 at 16:27
82

It seems like there is an entirely different method for changing the open files limit for each version of OS X!

For OS X Sierra (10.12.X) you need to:

1. Create a file at /Library/LaunchDaemons/limit.maxfiles.plist and paste the following in (feel free to change the two numbers (which are the soft and hard limits, respectively):

<?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>limit.maxfiles</string>
    <key>ProgramArguments</key>
    <array>
      <string>launchctl</string>
      <string>limit</string>
      <string>maxfiles</string>
      <string>64000</string>
      <string>524288</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>ServiceIPC</key>
    <false/>
  </dict>
</plist> 

2. Change the owner of your new file:

sudo chown root:wheel /Library/LaunchDaemons/limit.maxfiles.plist

3. Load these new settings:

sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist

4. Finally, check that the limits are correct:

launchctl limit maxfiles
6
  • worked perfectly, thanks! In my case the error manifested in a java process with the message IO Error: Bad file descriptor (Write failed)
    – agradl
    Mar 22, 2017 at 16:52
  • 1
    Also works on El Capitan 10.11.6 Apr 17, 2017 at 17:23
  • still cannot change the ulimit for shell. The maximum stays 1024 whatever I do
    – DataGreed
    Oct 6, 2017 at 0:46
  • At step 2 run: sudo chmod 600 /Library/LaunchDaemons/limit.maxfiles.plist sudo chown root /Library/LaunchDaemons/limit.maxfiles.plist
    – Hai Nguyen
    Jun 21, 2018 at 8:00
  • 1
    Works in MacOS Ventura 13.3
    – Hackeron
    Apr 5, 2023 at 12:57
46

Other option may be finding the culprit:

sudo lsof -n | cut -f1 -d' ' | uniq -c | sort | tail

For the last one you could see what files are open:

sudo lsof -n | grep socketfil

And kill the process if so desired

kill $pid

From the comments:

For what it's worth, you can also get a list of the process IDs with the most open files using

lsof -n +c 0 | sed -E 's/^[^ ]+[ ]+([^ ]+).*$/\1/' | uniq -c | sort | tail
9
  • Helpful! But sort on OS X (10.11) doesn't take -h. (Maybe -g?) Mar 3, 2017 at 14:52
  • 1
    For me worked well just without -h (OS X 10.12.3): sudo lsof -n | cut -f1 -d' ' | uniq -c | sort | tail
    – vearutop
    Mar 6, 2017 at 3:42
  • So be it without -h
    – sanmai
    Mar 6, 2017 at 10:27
  • 2
    Use lsof -n +c 0 to prevent truncating process name.
    – vaughan
    Jul 12, 2018 at 11:45
  • 1
    Running Catalina, and I prefer lsof -n +c 0 | sed -E 's/^([^ ]+[ ]+[^ ]+).*$/\1/' | uniq -c | sort | tail (ie, move the first open parenthesis further left to include the command name in the output). Gives me this: ``` ... 629 Google\x20Chrome 50163 669 phpstorm 89615 681 Microsoft\x20Outlook 89373 808 vpnkit-bridge 755 1176 zoom.us 1382 ``` Here, zoom, PID 1382, has 1176 open files, the most of any process on my system right now. Jul 19, 2020 at 4:16
42

You will need to increase your ulimit settings - it's pretty low on OS X these days - 256 by default. Add ulimit -n 4096 or similar to your ~/.profile or equivalent and that will solve it in your local environment. Run ulimit -a to check your current levels

To see the system settings, run this:

launchctl limit maxfiles

It is set quite a bit higher in Lion (10240) on a per process basis than it used to be. But if you are still hitting it there then you can set it higher using the same command with the desired levels. To make the changes permanent /etc/launchd.conf is where you need to add the relevant lines.

13
  • 2
    256? It's 2560 file descriptors for me and I've never changed it. The limit is 266 processes (c.f. ulimit -a).
    – slhck
    Jun 22, 2012 at 18:55
  • 2
    Same for me, 256 files on MacOS X Maverick
    – Climbatize
    Aug 9, 2014 at 6:44
  • 4
    256 on OS X Yosemite as well
    – Alexander
    May 28, 2015 at 9:52
  • 2
    256 on El Capitan, too.
    – TMN
    Apr 28, 2016 at 10:53
  • 1
    256 in Yosemite.
    – Jaec
    Jun 16, 2016 at 22:50
14

Folks, on Mavericks 10.9.4

ulimit -n 2048 works fine. You may need to launch a new login session.

6

For latest macOS (at the time of writing: 10.14.1), you can use sudo launchctl limit maxfiles 64000 524288 (by default it was 256), but it works only within current session. Use launchctl job from @ninjaPixel (https://superuser.com/a/1171028/760235) for permanent solution.

1
  • 1
    How did you come up with the number 524288? My previous values were 256 and unlimited. Oct 6, 2019 at 21:39
5

Similar to https://superuser.com/a/1171028/367819

To check the current limits on your Mac OS X system, run:

launchctl limit maxfiles

The last two columns are the soft and hard limits, respectively.

To adjust open files limits on a system-wide basis in Mac OS X Yosemite, you must create two configuration files. The first is a property list (aka plist) file in /Library/LaunchDaemons/limit.maxfiles.plist that contains the following XML configuration:

<?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>limit.maxfiles</string>
      <key>ProgramArguments</key>
        <array>
          <string>launchctl</string>
          <string>limit</string>
          <string>maxfiles</string>
          <string>200000</string>
          <string>200000</string>
        </array>
      <key>RunAtLoad</key>
        <true/>
      <key>ServiceIPC</key>
        <false/>
    </dict>
  </plist>

This will set the open files limit to 200000. The second plist configuration file should be stored in /Library/LaunchDaemons/limit.maxproc.plist with the following contents:

<?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>limit.maxproc</string>
      <key>ProgramArguments</key>
        <array>
          <string>launchctl</string>
          <string>limit</string>
          <string>maxproc</string>
          <string>2048</string>
          <string>2048</string>
        </array>
      <key>RunAtLoad</key>
        <true />
      <key>ServiceIPC</key>
        <false />
    </dict>
  </plist>

Both plist files must be owned by root:wheel and have permissions -rw-r--r--. This permissions should be in place by default, but you can ensure that they are in place by running sudo chmod 644 . While the steps explained above will cause system-wide open file limits to be correctly set upon restart, you can apply them manually by running launchctl limit.

In addition to setting these limits at the system level, we recommend setting the at the session level as well by appending the following lines to your bashrc, bashprofile, or analogous file:

ulimit -n 200000
ulimit -u 2048

Like the plist files, your bashrc or similar file should have -rw-r--r-- permissions. At this point, you can restart your computer and enter ulimit -n into your terminal. If your system is configured correctly, you should see that maxfiles has been set to 200000.


You can follow this article for more details.

https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c


Remember to restart your Mac to have the values effective.

2
  • Either the post should be marked as a duplicate if there is already an answer, otherwise, please post the relevant information from a link, as the link may not be valid forever.
    – zymhan
    May 30, 2019 at 1:04
  • Worked perfectly for me. Running Mojave 10.14.6 Mar 4, 2020 at 20:10
3

After all changes above my java didn't made more that 10000 files. Solution was this jvm flag -XX:-MaxFDLimit

1
  • White space is bad, m'kay? I had a space between -XX: and -MaxFDLimit and it wouldn't work. Thanks
    – Coder-guy
    Oct 1, 2020 at 14:01
2

Increasing the number of authorized files read and write should never be considered as a good common practice.

As sanmai and many suggested you could simply try to kill some overwhelming processes. Probably the ones involved in the increase of number of file manipulations.

1-/ Step one retrieve the most file consuming processes

lsof -n +c 0 | cut -f1 -d' ' | uniq -c | sort | tail

2-/ Step two use theses names to kill all the processes they are involving. beware of not killing systematically any file consuming process since it might be essential for your current activity.

ps -e -a |grep file-consuming-process |for i in `awk {'print$1'}`; do kill -9 $i; done

repeat the process until you kill the undesired mighty daemons.

Have fun :)

1

You can run

lsof -n

which process open too many files.

then kill it .

or

sysctl -w kern.maxfiles=20480

change it to bigger one.

1
  • 3
    Please explain how this answer differs from the ones already given. May 18, 2017 at 3:30
0

I encountered it while doing a chmod -R so I got it around by taking smaller steps, e.g.

# for each directory
find . -type d -exec chmod 755 {} \;
1
  • 1
    While this may be a work-around, it doesn't appear to actually answer the question. Perhaps explaining that you cannot get rid of the message and then proposing this as one way to make it less of an issue would improve your answer. Jan 4, 2017 at 21:11
0

I had this issue on a 2017 Macbook running Catalina. The issue was Spotify (which was up to date), and the Spotify setting "Show Local Files".

This setting allows Spotify to look through your downloads folder or other folders and for some reason it was opening and checking but not closing the files. Checking lsof -n this was actually over 7500 files including thousands of .jpg files as I had not cleaned out my downloads folder in a long while. Not sure why Spotify didn't close them, seems to be a bug.

Disabling this setting and restarting Spotify may work, alternatively just uninstalling will work.

0

For me, most of the suggested answers worked after I have restarted my device and run the mongorestore with internet browsers, Spotify, Slack etc. are closed. I am guessing opening a new terminal shell or turning off the apps does not release the resources immediately.

Therefore, if you are gonna use the mongorestore more than once in the same session, I'd advice to follow my suggestion above.

2
  • Avoid posting answers to old questions that already have well received answers unless you have something substantial and new to add.
    – Toto
    Mar 5, 2023 at 16:25
  • I think my comment is quite substantial, because the solutions provided were not working on their own for me and this error made me lose couple of days to fix. Also, the question is asked in 2012, received answers 2016, 2017, 2020.. My answer which is in early 2023 is not differentiating in terms of value of the contribution from others in my opinion.
    – Melih
    Mar 5, 2023 at 20:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .