我发现了许多引用,以增加Samba可用的打开文件数来解决问题.我认为这是一个好主意,我正在拼命地这样做……但无论我做什么,它都拒绝打开超过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这已经足够了.
我找不到任何可能干扰samba的apparmor配置文件.
我在/etc/init/smbd.conf中添加了一个限制nofile 25000 65000节
我在smb.conf中设置了max open files = 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,unable to open more! smbd's max open files = 50000 [2011/10/28 01:30:19,unable to open more! smbd's max open files = 50000 [2011/10/28 01:30:20,unable to open more! smbd's max open files = 50000
我已经确认,当使用lsof |打开大约1000个文件时会出现问题磁盘上的wc -l给我一个近似计数.无论我改变什么,它总是1000,其中出现“再试一次”按钮并且副本被中断.一旦它回落到1000以下,您可以再次单击尝试,它将恢复复制.
显然这是Windows 7或Samba中的一个错误,我不关心哪个,我关心的是修复它.为什么我的Samba不会打开超过1000个左右的文件,就像我要求它在很多方面做的那样？我需要改变一些其他限制吗？
编辑：symcbean有一个很好的建议.以下是插入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
另外,我正在运行版本2：3.4.7~dambg-1ubuntu3的samba.
解决方法
第一个问题,也是一个愚蠢的问题：nofiles应该是/etc/security/limits.conf中的nofile
另一个更重要的疏忽：虽然我确保pam_limits.so包含在/etc/pam.d/common-session中,但我没有注意到还有/etc/pam.d/common-session-noninteractive.后一个文件是samba使用的文件.
修复该问题似乎已经修复了samba,现在可以打开任意数量的文件描述符. Windows副本成功完成.另请注意：Samba确实使用了相应用户的ulimit,而不是smbd进程启动的ulimit,也没有root的ulimit.一旦你正确配置(两个？)/etc/pam.d/common-session-noninteractive和/etc/pam.d/samba使用pam_limits,/ etc / security / limit.conf就可以设置它.所以
至于另一个问题,我的用户卡在1024硬/ 1024软限制,这是一些问题的组合.首先,尽管有/etc/pam.d/sshd,ssh守护进程不使用PAM,除非你修改/ etc / ssh / sshd_config以使用“UsePAM yes”.默认为“no”,如果不使用PAM,pam_limits.so(负责应用limits.conf)甚至不会发挥作用.
相反,非PAM登录的默认ulimits似乎从pid 1(通常是“init”)继承.您可以使用cat / proc / 1 / limits检查这些默认的pid 1限制.不幸的是,据我所知,这些限制被设置为内核中的默认值.似乎没有任何方法可以修改它们,只需重新编译内核,或说服非PAM应用程序使用PAM.
我还想提供一些建议,即cat / proc /< anypid> / limits是调试您可能遇到问题的任何特定进程限制的好方法.我希望我早点发现.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
