Too many open files

E

Eduard

I run a fairly busy Samba server that hosts media files for a website. I am running into an issue where my logs are reporting 'Too many open files'

Below is a line that repeats frequently in daemon.log:

Sep 18 xx:xx:xx xxxxxx smbd[xxxx]: [2025/09/18 xx:xx:xx.xxxxxxx, 0] ../../lib/util/debug.c:1274(reopen_one_log)
Sep 18 xx:xx:xx xxxxxx smbd[xxxx]: reopen_one_log: Unable to open new log file '/var/log/samba4/log.smbd': Too many open files

I have looked through this forum and elsewhere online and found a number of things to look at, and it appears like I should not be having this issue.

sysctl -a | grep files
kern.maxfiles: 100000000
kern.maxfilesperproc: 1000000
kern.openfiles: 85175

Output of the above does include many entries about too many open files such as:


kern.maxfiles limit exceeded by uid xxxxx, (smbd) please see tuning(7)


The above lists not just smbd, but other processes.

[xxxx@xxxxxxx /etc]# ulimit -n
1000000

I am not running any jails.

From what I can tell, the login class for the process is default, so I added this to login.conf and ran cap_mkdb but that did not stop the messages

:openfiles=unlimited:\


We recently updated from 13.5 to 14.3 but this was happening prior to this update.

Any guidance would be appreciated! From what I can tell, I should have plenty of 'space' for open files, but clearly I am missing something. I will be happy to supply configs or other information necessary.
 
see tuning(7):

The kern.maxfiles sysctl determines how many open files the system
supports. The default is typically a few thousand but you may need to
bump this up to ten or twenty thousand if you are running databases or
large descriptor-heavy daemons. The read-only kern.openfiles sysctl may
be interrogated to determine the current number of open files on the
system.
 
Thanks cracauer@,

This is where I am pulling my few hairs out!

If I tail -f daemon.log I get the message repeating very consistently, but when I check kern.openfiles against kern.maxfiles it seems to me I have plenty of 'room' to open more files.


Sep 18 15:59:56 xxxxxx smbd[xxxx]: [2025/09/18 15:59:56.431188, 0] ../../lib/util/debug.c:1274(reopen_one_log)
Sep 18 15:59:56 xxxxxx smbd[xxxx]: reopen_one_log: Unable to open new log file '/var/log/samba4/log.smbd': Too many open files
Sep 18 16:00:03 xxxxxx smbd[xxxx]: [2025/09/18 16:00:03.672516, 0] ../../lib/util/debug.c:1274(reopen_one_log)
Sep 18 16:00:03 xxxxxx smbd[xxxx]: reopen_one_log: Unable to open new log file '/var/log/samba4/log.smbd': Too many open files
Sep 18 16:00:08 xxxxxx smbd[xxxx]: [2025/09/18 16:00:08.494031, 0] ../../lib/util/debug.c:1274(reopen_one_log)
Sep 18 16:00:08 xxxxxx smbd[xxxx]: reopen_one_log: Unable to open new log file '/var/log/samba4/log.smbd': Too many open files
Sep 18 16:00:25 xxxxxx smbd[xxxx]: [2025/09/18 16:00:25.130407, 0] ../../lib/util/debug.c:1274(reopen_one_log)
Sep 18 16:00:25 xxxxxx smbd[xxxx] reopen_one_log: Unable to open new log file '/var/log/samba4/log.smbd': Too many open files
^C
[xxxxxx@xxxxxx /var/log]# sysctl kern.openfiles
kern.openfiles: 99429
[xxxxxx@xxxxxx /var/log]# sysctl kern.maxfiles
kern.maxfiles: 100000000
 
When I tried editors/vscode several years ago, and tried to open /usr/src, vscode want to scan everything (and keep opened at least until it finishes) under there, and kern.maxfiles="25000" was insufficient.

I needed to bump it to kern.maxfiles="250000".

I've already stopped using it, but keeping the value for safety.
 
Just checked my sysctl.conf, and kern.maxfiles="200000", but TBH I can’t remember when nor why I changed it.
Last edit was in Nov ’23, but that’s telling me nothing.

Man, MS(G35) is such a bitch 🤬
 
T-Aoki said:
Maybe devs of vscode don't expect to be used in such a large project, or expect open files are unlimited if free virtual memories are available.
Click to expand...

You would think many Microsoft projects have more files than FreeBSD.

But maybe Windows does indeed have a dynamic maxfiles.
 
cracauer@ said:
You would think many Microsoft projects have more files than FreeBSD.

But maybe Windows does indeed have a dynamic maxfiles.
Click to expand...
AFAIK _theoretical_ limit is 2^24, but for single process that uses the default C run-time libs limit is 512. Just checked net config server on Win10 Pro and Maximum open files per session 16384, but that’s for net connections
 
So running lsof and the command from covacat show me consistent numbers as sysctl -a | grep files which are below the limit I have set for kern.maxfiles and kern.maxfilesperproc

I'm half way wondering if I am hitting some edge case or bug with Samba. The log still is showing me the message about too many open files to create the log.smbd file, however the file does exist and its being updated with an entry of

[2025/09/19 08:26:41.207838, 1] ../../source3/modules/vfs_posixacl.c:192(smb_ace_to_internal)
ACL tag type ACL_EVERYONE. FreeBSD with ZFS? Use 'vfs objects = zfsacl'

I know the above says to use vsfs objects = zfsacl, but if we enable that then we get odd permission related issues writing which we were unable to resolve, but we haven't tried again after updating the system.

Here is the output of the command you posted covacat (I have obfuscated users names, but I will add that the ones with a + are mapped to Active Directory users)

76803 XXXXXX smbd 58602
5202 XXXXXX+ smbd 49496
5150 XXXXXX+ smbd 38116
5140 XXXXXX+ smbd 30068
5137 XXXXXX+ smbd 38361
5114 XXXXXX+ smbd 49028
5100 XXXXXX+ smbd 38168
5069 XXXXXX+ smbd 49594
5042 XXXXXX+ smbd 29813
5012 XXXXXX+ smbd 29468
47 XXXXXX smbd 61440
44 XXXXXX smbd 59832
44 XXXXXX smbd 59058
44 XXXXXX+ smbd 31439
43 XXXXXX smbd 59228
41 XXXXXX winbindd 58213
39 XXXXXX smbd 57287
39 XXXXXX samba-dcerpcd 82279
37 XXXXXX smbd 46443
37 XXXXXX smbd 45991


The process with the most open files is this:
smbd: notifyd (smbd)

Unless someone has some ideas on this issue, I am starting to think this is more of a Samba issue and less so of a 'Too many open files' OS issue...
 
You must log in or register to reply here.
Back
Top