Сервер: RHEL 5.9 / smbd 3.0.33 - Клієнти: різні, хоча всі використовували поточний mount.cifs (5.2)
Я вже вирішив цю проблему, але для пошуку цих кодів помилок був такий кошмар, я відчував, що це потребує універсального документування.
Симптоми : непередбачуваний, переривчастий збій монтажу від одного конкретного клієнта cifs до сервера linux samba. Усі мої клієнти linux пам’ятіть будинки користувачів під час входу. Випадково та епізодично кріплення домашнього режиму почали виходити з ладу на одній машині. Логіни та кріплення продовжували бездоганно працювати на всіх інших клієнтів. Спочатку я думав, що незвичний обсяг активності на зламаному клієнті спричиняє 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 / фс / CIFS / cifsFYI' диваки до mount.cifs налагодження (запис в / вар / журналу / налагодження). Ось хороша частина (виглядаєш знайомою?):
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) є досить неінформативною (man page не допомагає, THX хлопці). Розширений пошук в Інтернеті виявляє, що це звичайний код помилки, а також підтверджує його як неінформативний.
Час перевірити на сервері! Встановіть 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
Майже там… із архіву списку розсилки smb я знайшов когось, що повідомляє про подібну проблему, ідентифіковану як обмежений обмеження на частку доступу до окремого smb-з'єднання. Список відкритих акцій на сервері:
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 $ від клієнта? Чи є спосіб збільшити максимум # з'єднань на одну акцію (не те, що це допомогло б у цьому випадку)? Я не бачив цього в документах.