Serwer: RHEL 5.9 / smbd 3.0.33 - Klienci: różni, chociaż wszyscy używali obecnego mount.cifs (5.2)
Rozwiązałem już ten problem, ale polowanie na te kody błędów było koszmarem i czułem, że potrzebuje uniwersalnej dokumentacji.
Objawy : Nieprzewidywalna, przerywana awaria montowania z jednego konkretnego klienta cifs na serwer Linux Samba. Wszyscy moi klienci Linux-a pam_mount domy użytkownika podczas logowania. Losowo i sporadycznie domowe monitory zaczęły zawodzić na jednej maszynie. Loginy i podłączenia nadal działały bezbłędnie na wszystkich innych klientach. Początkowo myślałem, że niezwykła aktywność na zepsutym kliencie powoduje, że smbd wariuje, ale sporadyczne awarie utrzymują się nawet po zaniku użycia.
Próba ręcznego zamontowania kończy się niepowodzeniem i zgłasza:
Errors from underlying mount program
mount error(12): Cannot allocate memory
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Ustaw <debug enable="1"/>w /etc/security/pam_mount.conf.xml, aby uzyskać więcej informacji od 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 również zgłosił to zdarzenie:
kernel: [4316790.256149] CIFS VFS: cifs_mount failed w/return code = -12
'echo 1> / proc / fs / CIFS / cifsFYI' korb się mount.cifs debugowania (zapisy do / var / log / debug). Oto dobra część (wyglądasz znajomo?):
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
W tym momencie dosłownie nie ma innych informacji dostępnych po stronie klienta. żądanie montowania cifs gaśnie, a klient umiera prawie natychmiast. Błąd mount.cifs (12) jest dość nieinformacyjny (strona man nie pomaga, dziękuję). Rozległe wyszukiwanie w Internecie ujawnia, że jest to częsty kod błędu, a także potwierdza, że jest to informacja.
Czas sprawdzić na serwerze! Ustaw log level = 3na smbd w /etc/samba/smb.conf (z książki Korzystanie z Samby: „Poziomy powyżej 3 są przeznaczone dla programistów i zrzucają ogromne ilości tajemniczych informacji.” Lol!). Oto odpowiedni wiersz:
[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
Prawie tam ... z archiwum list mailowych smb Znalazłem kogoś zgłaszającego podobny problem, zidentyfikowany jako ustalony limit akcji dla pojedynczego połączenia smb. Lista otwartych udziałów na serwerze:
smbstatus -S | grep <serverIP> | wc -lzwrócił 2048 . Bardzo rzucające się w oczy.
Właściwie sprawdzam wyniki smbstatus -Sujawnionych tysięcy wpisów dla „IPC $”. Dokumenty Samby na temat IPC $ ujawniają, że wiąże się to z anonimowym przeglądaniem zasobów i dostępem do „niektórych innych zasobów”. Ustawiam odmowę hosta na serwerze w /etc/samba/smb.conf:
[IPC$]
hosts deny = 0.0.0.0/0
Działa teraz świetnie. OK, mam nadzieję, że coś tu pomoże jakiejś biednej duszy w przyszłości.
Myślę, że w duchu strony zadam pytanie: Dlaczego smbd nie posprząta akcji IPC $? Dlaczego warto ustanowić jedno IPC $ na połączenie użytkownika z udziałem zamiast jednego na połączenie klienta? Czy możesz wyłączyć tworzenie udziałów IPC $ po stronie klienta? Czy istnieje sposób na zwiększenie maksymalnej liczby połączeń na udział (nie to by pomogło w tym przypadku)? Nie widziałem tego w dokumentach.