我正在运行一个Ubuntu 10.04（lucid）samba文件服务器。 我有一个Windows 7的客户端，一次做数以千计的小文件的副本打开大量的文件。 它收到错误“太多的打开的文件”，在这一点上等待几秒钟，然后点击“再试一次”恢复下载。
我发现了很多参考文献，说增加可用于Samba解决问题的打开文件的数量。 我认为这是一个好主意，我正在拼命地尝试这样做…但不pipe我做什么，它拒绝打开超过1024个文件，复制问题不会消失！
这是我试过的：
我已经设置了ulimit -n 25000 。
我还设置了/etc/security/limits.conf来：
* soft nofiles 25000 * hard nofiles 65000 root soft nofiles 25000 root hard nofiles 65000
我已经确保/etc/security/limits.d中没有任何内容覆盖这些内容。
我已经检查了sysctl fs.file-max = 199468，这已经足够了。
我无法find任何可能会干扰桑巴的apparmorconfiguration文件。
我已经添加了limit nofile 25000 65000节到/etc/init/smbd.conf
我在smb.conf中设置了最大打开的文件= 50000，并确认它通过samba日志文件生效：
[2011/10/28 01:30:16, 0] smbd/open.c:151(fd_open) Too many open files, unable to open more! smbd's max open files = 50000 [2011/10/28 01:30:18, 0] lib/sysquotas.c:426(sys_get_quota) sys_path_to_bdev() failed for path [.]! [2011/10/28 01:30:18, 0] lib/sysquotas.c:426(sys_get_quota) sys_path_to_bdev() failed for path [.]! [2011/10/28 01:30:18, 0] smbd/open.c:151(fd_open) Too many open files, unable to open more! smbd's max open files = 50000 [2011/10/28 01:30:19, 0] smbd/open.c:151(fd_open) Too many open files, unable to open more! smbd's max open files = 50000 [2011/10/28 01:30:20, 0] smbd/open.c:151(fd_open) Too many open files, unable to open more! smbd's max open files = 50000
我已经确认，当使用lsof | wc -l打开大约1000个文件时，会发生这个问题 lsof | wc -l在磁盘上给我一个近似数。 不pipe我改变了什么，总是1000，“再试一次”button出现，复制被中断。 一旦它回落到1000以下，你可以再次点击试一次，它会恢复复制。
显然这是Windows 7或Samba中的一个bug，我不在乎哪个，我所关心的是修复它。 为什么我的Samba不能打开超过1000个左右的文件，就像我要求它在很多方面做的那样？ 有什么其他限制我需要改变？
编辑：symcbean有一个很好的build议。 以下是将ulimit -a > /tmp/samba-ulimits插入到/etc/init/smb.conf的前脚本部分的结果
time(seconds) unlimited file(blocks) unlimited data(kbytes) unlimited stack(kbytes) 10240 coredump(blocks) 0 memory(kbytes) unlimited locked memory(kbytes) 64 process 15969 nofiles 25000 vmemory(kbytes) unlimited locks unlimited
另外，我正在运行samba的版本2：3.4.7〜dfsg-1ubuntu3。
好的，我已经解决了我的问题，这样做至less可以在Ubuntu中更好地理解ulimits的工作原理。 有一些问题，我想我已经整理出来了。
第一个问题，也是一个愚蠢的问题： nofiles应该在/etc/security/limits.conf
另一个更重要的监督：虽然我确保pam_limits.so包含在/etc/pam.d/common-session ，但我没有注意到/etc/pam.d/common-session交互。 后一个文件是桑巴使用的文件。
修复这个问题似乎有固定的samba，现在可以打开任意数量的文件描述符。 Windows副本成功完成。 另外请注意 ：Samba确实使用适当的用户ulimit，而不是ulimits开始的smbd进程，也不是root的ulimit。 在/etc/pam.d/common-session-noninteractive和/etc/pam.d/samba中使用pam_limits（/？/etc/pam.d/common-session-noninteractive）来正确configuration/etc/security/limits.conf。所以
至于另一个问题，我的用户被困在1024硬/ 1024软限制，这是几个问题的组合。 首先，尽pipe有/etc/pam.d/sshd ，但ssh守护程序不使用PAM，除非将/etc/ssh/sshd_config修改为“UsePAM yes”。 缺省值是“no”，不使用PAM，pam_limits.so（负责应用limits.conf）甚至不起作用。
相反，非PAMlogin的默认限制似乎从pid 1（通常是“init”）inheritance。 您可以使用cat /proc/1/limits来检查那些默认的pid 1 cat /proc/1/limits 。 不幸的是，据我所知，这些限制在内核中被设置为默认值。 似乎没有什么办法可以在重新编译内核之前修改它们，或者说服非PAM应用程序使用PAM。
我也只是想提供一个build议，即cat /proc/<anypid>/limits是debugging任何特定进程的限制的好方法。 我希望早点发现。
我正在使用Ubuntu 14.04 lts，需要几个小时来实现以下内容：
必须用以下代码插入一行：
限制nofile 16384 16384
重新启动后，所有工作正常，ps ax告诉你samba和cat / proc / 799 / limits的进程ID显示进程799（与进程ID交换799）正确的最大打开文件限制。
也许Samba初始化脚本有类似于ulimit -SHn 1024东西ulimit -SHn 1024呢？ 请参阅/etc/init.d/smb或任何您的初始化脚本。