Сервер самбы Linux: cifs_mount привел код w/return к сбою =-12

Сервер: RHEL 5.9 / smbd 3.0.33 - Клиенты: различный, хотя все использовали текущий mount.cifs (5.2)

Я уже решил эту проблему, но это был такой кошмар для выслеживания этих кодов ошибок, я чувствовал, что этому было нужно универсальное документирование.

Признаки: Непредсказуемый, неустойчивый отказ монтирования с одного определенного клиента CIFS на сервер самбы Linux. Все мои клиенты Linux pam_mount пользователь размещают при входе в систему. Случайным образом, и эпизодически домашний dir монтируется, начал перестать работать на одной машине. Логины и монтируются продолженный для работы безупречно над всеми другими клиентами. Первоначально я думал, что необычный объем действия по поврежденному клиенту заставлял smbd беситься, но неустойчивые отказы задержались даже после того, как использование утихло.

Попытка смонтироваться ручными сбоями и отчетами:

Errors from underlying mount program
mount error(12): Cannot allocate memory
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Набор <debug enable="1"/> в /etc/security/pam_mount.conf.xml для получения большего количества информации от pam_mount:

command: 'mount' '-t' 'cifs' '//my_server/watdo' '/home/watdo' '-o' 'user=watdo,uid=666,gid=666'
pam_mount(misc.c:38): set_myuid<pre>: (ruid/rgid=0/0, e=0/0)
pam_mount(misc.c:38): set_myuid<post>: (ruid/rgid=0/0, e=0/0)
pam_mount(mount.c:64): Errors from underlying mount program:
pam_mount(mount.c:68): mount error(12): Cannot allocate memory
pam_mount(mount.c:68): Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)`

О /var/log/kern.log также сообщают относительно этого события:

kernel: [4316790.256149] CIFS VFS: cifs_mount failed w/return code = -12

'эхо 1>/proc/fs/cifs/cifsFYI' заводные рукоятки mount.cifs отладка (пишет в/var/log/debug). Вот хорошая часть (выглядите знакомыми?):

CIFS Session Established successfully
For smb_command 117
Sending smb:  total_len 88
cifs_sync_mid_result: cmd=117 mid=54307 state=4
Mapping smb error code 0xc0000205 to POSIX err -12

В этой точке нет буквально никакой другой информации, доступной на стороне клиента. cifs монтируют, что запрос выходит, и клиент умирает почти сразу. ошибка mount.cifs (12) довольно неинформативна (страница справочника не помогает, парни спасибо). Обширный интернет-поиск показывает, что это - код распространенной ошибки, также подтверждает это как неинформативное.

Время для проверения сервера! Набор log level = 3 для smbd в/etc/samba/smb.conf (от Использования книги Samba: "Уровни выше 3 для использования разработчиками и выводят огромные объемы загадочной информации". lol!). Вот соответствующая строка:

[2013/02/08 10:18:03, 3] smbd/error.c:error_packet_set(106) error packet at smbd/reply.c(514) cmd=117 (SMBtconX) NT_STATUS_INSUFF_SERVER_RESOURCES

Почти там... от кого-то архив списка рассылки я нашел, что кто-то сообщающий о своего рода подобной проблеме, идентифицированной как привязанная доля, ограничивает на человеке кого-то соединение. Список открытые доли на сервере:

smbstatus -S | grep <serverIP> | wc -l возвращенный 2048. Очень заметный.

На самом деле исследуя вывод smbstatus -S показанные тысячи записей за 'IPC$'. Документы Samba о IPC$ показывают, что он связан с анонимным просмотром доли и доступом к "некоторым другим ресурсам". Я установил хост, отклоняют на сервере в/etc/samba/smb.conf:

[IPC$]
hosts deny = 0.0.0.0/0

Работает отлично теперь. Хорошо, надо надеяться, что-то здесь помогает некоторой плохой душе некоторое время в будущем.

Я предполагаю в духе сайта, который я задам вопросу: Почему smbd не очистил бы доли IPC$? Почему устанавливают один IPC$ за пользовательское соединение к доле, а не один на соединение клиента? Можно ли отключить создание доли IPC$ от стороны клиента? Существует ли способ увеличить макс. # соединения на долю (не, которому это помогло бы в этом случае)? Я не видел его в документах.