I'm on Ubuntu 17.04. Trying to increase the open file limit, and none of the instructions I've found online are working. I can go up to 4096, but can't go past that.

$ ulimit -n
$ ulimit -n 4096
$ ulimit -n

That works. This doesn't:

$ ulimit -n 4097
bash: ulimit: open files: cannot modify limit: Operation not permitted

It appears to be because of the hard limit:

$ ulimit -Hn

I've tried adding these lines to /etc/security/limits.conf:

*                hard    nofile          65535
*                soft    nofile          65535
root             soft    nofile          65535
root             hard    nofile          65535

Also added this line to /etc/pam.d/common-session and /etc/pam.d/common-session-noninteractive:

session required pam_limits.so

Since doing that, I've rebooted my computer. Changes to limits.conf don't seem to affect anything. The hard limit is still stuck at 4096, preventing me from going any higher. How do I increase my open files limit?

Here's some additional config info:

$ cat /proc/sys/fs/file-max 

5 Answers 5


OK, I finally figured this out. The limits I was setting in /etc/security/limits.conf were indeed being applied, but not to the graphical login. This can be verified from a terminal window:

$ ulimit -n
$ su mkasberg
$ ulimit -n

More research led me to this bug report, which got me pointed in the right direction. In order to modify the limit that is used by the login shell, we need to add the following line to /etc/systemd/user.conf:


That change works, but only affecting the soft limit. (Leaving us capped with a hard limit of 4096 still.) In order to affect the hard limit, we must modify /etc/systemd/system.conf with the same changes.

The changes I made in /etc/pam.d were not necessarily; it's already working, at least on Ubuntu. Also, it was not necessary to add the lines root and * in limits.conf; adding the username alone (mkasberg in my case) was sufficient.

In Summary

If you want to increase the limit shown by ulimit -n, you should:

  • Modify /etc/systemd/user.conf and /etc/systemd/system.conf with the following line (this takes care of graphical login):

  • Modify /etc/security/limits.conf with the following lines (this takes care of non-GUI login):

     mkasberg hard nofile 65535
     mkasberg soft nofile 65535
  • Reboot your computer for changes to take effect.

  • 7
    DefaultLimitNOFILE=65535 did the trick. But why /etc/security/limits.conf does'nt work? Jan 4, 2018 at 7:44
  • 11
    The GUI login uses systemd, which apparently has it's own configuration (/etc/systemd/system.conf) that is independent of the normal configuration for terminal sessions (/etc/security/limits.conf). I don't know enough about systemd to know why it was implemented this way.
    – mkasberg
    Jan 4, 2018 at 17:22
  • 2
    @Suvitruf because it's ignored in a systemd system. I'm posting an answer.
    – Marc.2377
    May 12, 2018 at 21:54
  • 2
    Just want to point out that limits for root user can't be specified by * or group specifiers. root literal must be specified explicitly. Dec 30, 2018 at 16:43
  • 3
    This works for me, after a reboot. May 18, 2019 at 7:46

No need to change anything in the /etc/security/limits.conf file, it is ignored if you are using systemd.

(reproducing a modified answer to another question on the network...)

An alternative for those who prefer not to edit the default /etc/systemd/system.conf and /etc/systemd/user/conf files:

  1. create a new file /etc/systemd/system.conf.d/limits.conf with these contents:

  2. run systemctl daemon-reexec as root

  3. logout and login again

  4. check your new limit with ulimit -n.

Refer to the systemd-system.conf manpage for details.

  • On my Ubuntu 18.10 system the file in question is at /etc/systemd/system.conf. Making the change there appears to have done the trick, thank you. Mar 30, 2019 at 22:44
  • 3
    Just logging out for me did not work (Ubuntu 18.04) but restarting did the job. Very elegant solution, thanks.
    – stann1
    Apr 11, 2019 at 9:39
  • Contrary to your claim, limits.conf is still loaded by pam_limits.so. systemd overrides DefaultLimitNOFILE regardless, as stated in its man page. Feb 27, 2023 at 17:33
  • This didn't work for me. @mkasberg's solution worked for me. Jun 9, 2023 at 1:19

TL;DR I felt the need to concentrate the answers, so they're easier to find. Took me ages to get all the pieces together to make it work correctly ...

There are 2 locations to be considered.

  1. GUI session

    $ grep DefaultLimitNOFILE /etc/systemd/system.conf

    or better here:

    $ grep NOFILE /etc/systemd/system.conf.d/limits.conf
  2. shell environment

    $ grep nofile /etc/security/limits.conf
    user soft nofile 65535
    user hard nofile 65535`

    or better here:

    $ grep nofile /etc/security/limits.d/user.conf
    user soft nofile 65535
    user hard nofile 65535
  3. After altering the settings in the above files, reboot and then check the limits with: ulimit -n -Hn -Sn

  1. edit /etc/systemd/system/sonar.service

  2. add these two line under Service




  1. systemctl daemon-reload
  2. systemctl restart sonar

this works for me.


Using Ubuntu 17.04 I got the described hard limit:

[email protected]:~$ ulimit -Hn

I could lower it using ulimit, but not increase it, just as the question describes it. ulimit manual describes:

only root can increase the hard limit.

So I tried to set a higher limit in /etc/security/limits.conf like this:

user hard nofile 9999

and a fresh login like ssh localhost -l user gave me the new limit:

[email protected]:~$ ulimit -Hn

I hope this works for you too.

You must log in to answer this question.

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