Jak zapobiec blokowaniu plików przez sambę po rozłączeniu się klienta?

11

Tutaj mam serwer Samba (Debian 5.0) skonfigurowany do obsługi profili Windows XP.

Klienci łączą się z tym serwerem i pracują na swoich profilach bezpośrednio w udziale samby (profil nie jest kopiowany lokalnie).

Od czasu do czasu klient może nie zostać poprawnie zamknięty i dlatego system Windows nie zwalnia blokad plików. Patrząc na tabelę blokowania samby, widzimy, że wiele plików jest nadal zablokowanych, nawet jeśli klient nie jest już podłączony. W naszym przypadku wydaje się, że dzieje się tak w przypadku plików blokujących utworzonych przez Mozilla Thunderbird i Firefox. Oto przykład tabeli blokującej sambę:

# smbstatus -L | grep DENY_ALL | head -n5
Pid          Uid        DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
15494        10345      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user1   app.profile/user1.thunderbird/parent.lock   Mon Nov 22 07:12:45 2010
18040        10454      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user2   app.profile/user2.thunderbird/parent.lock   Mon Nov 22 11:20:45 2010
26466        10056      DENY_ALL   0x3019f     RDWR       EXCLUSIVE+BATCH  /home/CORP/user3   app.profile/user3.firefox/parent.lock   Mon Nov 22 08:48:23 2010

Widzimy, że pliki zostały otwarte przez system Windows i nałożyły blokadę DENY_ALL.

Teraz, gdy klient ponownie łączy się z tym udziałem i próbuje otworzyć te pliki, samba mówi, że są zablokowane i odmawia dostępu.

Czy jest jakiś sposób obejścia tej sytuacji, czy coś mi brakuje?

Edit: Chcielibyśmy, aby uniknąć wyłączania blokady plików na serwerze samby, bo tam dobre powody, aby mieć te włączone.

Jean-Francois Chevrette
źródło

Odpowiedzi:

11

poniższe kroki pomogły mi rozwiązać ten problem przy wielu okazjach:

  1. Zaloguj się do serwera samby.
  2. Uruchom „smbstatus”.
  3. Znajdź pid procesu, który ma blokadę pliku w trzeciej części wyniku.
  4. Sprawdź, czy pasuje do oczekiwanego użytkownika i nazwy hosta w pierwszej i drugiej sekcji danych wyjściowych smbstatus.
  5. Uruchom „ps -ef” i zobacz, jak długo trwa smbd z tym pid.
  6. Jeśli działał jeszcze przed ostatnim uruchomieniem komputera, pozostaje smbd. Zabij TYLKO TEN JEDEN smbd. (I upewnij się, że otrzymałeś właściwy - powinien to być ten, w którym rodzic nie ma pid równy 1.)
Socceroos
źródło
Ponadto może się okazać, że niektóre smbd pids działają od kilku godzin, a pliki, które zablokowali, są tymi, których potrzebujesz. Jak wyżej, po prostu zabij te procesy i wszystko powinno być w porządku. Jeśli przypadkowo zabijesz główny proces smbd, możesz go ponownie uruchomić za pomocą tego polecenia: sudo /etc/init.d/smbd restart
Socceroos
5

Spójrz na:

reset on zero vc = yes / no

i sprawdź, czy to rozwiąże problem, czy nie.

Ze strony podręcznika smb.conf:

Ta opcja logiczna kontroluje, czy konfiguracja sesji przychodzącej powinna zabijać inne połączenia przychodzące z tego samego adresu IP. Jest to zgodne z domyślnym zachowaniem systemu Windows 2003. Ustawienie tego parametru na tak staje się konieczne, gdy masz niestabilną sieć, a Windows decyduje się na ponowne połączenie, podczas gdy stare połączenie nadal ma pliki z otwartymi trybami udostępniania. Pliki te stają się niedostępne przez nowe połączenie. Klient wysyła zero VC dla nowego połączenia, a Windows 2003 zabija wszystkie inne połączenia pochodzące z tego samego adresu IP. W ten sposób zablokowane pliki są ponownie dostępne. Należy pamiętać, że włączenie tej opcji spowoduje zabicie połączeń za maskaradującym routerem.

Edycja :
Właśnie pomyślałem o innym możliwym rozwiązaniu. Możesz zrobić coś takiego w tym udziale.

veto oplock files = /*.lock/

To tylko zapobiegnie blokowaniu plików .lock.

3dinfluence
źródło
0

Niektórzy bardzo sprytni ludzie na Sambie postanowili usunąć tę opcję i nie ma jej na zastąpienie.

Do tej pory dla kompatybilności SMB, ponieważ jest to rzeczywiście domyślne zachowanie wygranej.

O ile użytkownik nie jest zaznajomiony z linią poleceń i sposobem zabijania otwartych plików / procesów, musisz zrestartować SMBD lub sam serwer, aby to wyczyścić.

Cudownie zrobione, Samba.org.

Michał
źródło
Czy masz na to powód?
BE77Y
Musisz się przyjrzeć kilku, aby się tam dostać, ale: lists.samba.org/archive/samba-technical/2011-July/078621.html (pokaż proces myślowy i koleżanki błagające, aby go nie usuwać) listy .samba.org / archive / samba-technical / 2008-October /… (pokazuje, że parametr został usunięty w 4.0)
Michael
Począwszy od 2019 r., W Debian 9 - Samba 4.5.12, reset on zero vcopcja jest nadal wymieniona w instrukcji, a także wyświetlana przez testparm. Więc albo wrócił, albo naprawdę nie został usunięty.
mivk
0

Miałem podobny problem, klient zawiesił się podczas kopiowania dużego pliku, a plik został zablokowany po ponownym uruchomieniu. Na szczęście nie zdarza się to często, ale irytująca jest konieczność zabicia procesu samby. reset on zero vcWydawało się, że to tylko rozwiązanie, ale podobno zostało usunięte z Samba4, chociaż wersja 4.7.6 na Fedorze (27) wciąż go ma (prawdopodobnie załatane przez RH). Zresztą i tak niewiele to pomoże, ponieważ strona podręcznika mówi teraz, że działa tylko z SMB1 (którego nie należy już używać) i nie robi nic na połączeniach SMB2 i SMB3, jedyny sposób na poradzenie sobie z tym jest wymieniony w wątek połączony przez Micheal . Nie znam uzasadnienia usunięcia i co jest tak złego w tymreset on zero vc, Rozważałbym użycie limitu czasu tcp w tym celu bardziej jak hack. W każdym razie coś rozsądnego może być np

socket options = TCP_NODELAY SO_KEEPALIVE TCP_KEEPIDLE=30 TCP_KEEPCNT=3 TCP_KEEPINTVL=3

Spowoduje to zabicie połączenia około 40 sekund (30 + 3 * 3) po ostatniej komunikacji, co zwykle jest więcej niż wystarczające do zauważenia awarii i ponownego uruchomienia (biorąc pod uwagę, że stos TCP serwera jest wystarczająco inteligentny, aby zamknąć połączenie, gdy klient odrzuca pakiety utrzymywania aktywności po ponownym uruchomieniu).

Zauważ, że to zwiększa obciążenie twojej sieci, ale wątpię, że jest to zauważalne nawet w przypadku wielu klientów.

Jakob
źródło
Czy wiesz, czy to pomaga w dziwnym problemie wątku zombie klienta „Windows 10”? Wielu moich klientów Windows10 w kilku witrynach zaczęło zostawiać setki (czasami tysiące) wątków zombie, które są przypisywane do „nikogo nie grupują”, dopóki ich proces obsługi nie zostanie zabity / wycofany. Zwykle ustawienie deadtime = 10to czyściłoby to, ale z blokadami plików trwającymi na połączeniach SMB3_11 na zawsze, nie ma to żadnego wpływu, ponieważ czas oczekiwania nie będzie sprawdzany, gdy fileloki dla PID nadal istnieją. Niezwykle frustrujące.
zxq9
Nigdy nie słyszałem o opisywanym przez ciebie problemie. deadtimenic nie robi, jeśli twoi klienci mają otwarte pliki, więc pytanie brzmi, które pliki pozostają otwarte. Ale to prawdopodobnie zupełnie inna kwestia niż omawiana tutaj, więc powinieneś otworzyć na to nowe pytanie. Moja socket optionssugestia pomaga tylko w przypadku połączeń, które nie są poprawnie zamknięte (ponieważ klient ulega awarii, awarii sieci itp.), Ale prawdopodobnie nie, jeśli klienci WX po prostu łączą się z serwerem bez dalszych działań lub przy użyciu jakiejś anonimowej sesji (co nobody.nogroupsugeruje ).
Jakob
Wydaje się, że istnieje jedno pytanie dotyczące tego problemu, ale bez realnego rozwiązania. Wygląda na to, że może to być problem samby, który można naprawić w nowszej wersji.
Jakob
Jest wiele wzmianek na ten temat na liście mailingowej, nigdzie nie przedstawiono żadnego rzeczywistego rozwiązania, a żadna wersja, którą wypróbowałem (każda obecna gałąź, ale 4.9) nie rozwiązuje problemu. Dotyczy to tylko klientów Windows10. Sprawa nobody: nogroup jest kłopotliwa, ponieważ goście są wyłączani globalnie, żadne udziały ich nie akceptują, a PID wpisów nobody jest zawsze taki sam jak pojedynczy prawidłowy wpis z prawidłową nazwą użytkownika. Widzisz więc 12345 someuser somegroup...jeden wpis, a następnie 800 12345 nobody nogroup ...wpisów, ale tylko garść blokad plików (nie 800). Bardzo dziwne. Wpływa teraz na 3 z moich witryn klienckich.
zxq9
Staje się to jedynie ograniczeniem zasobów w witrynach o wysokiej aktywności i dlatego uważam, że nie zwraca na to uwagi. Przez większość czasu nie ma problemu, więc ludzie po prostu go nie zauważają, a to w pewnym sensie usuwa się, gdy klienci faktycznie zamykają swoje połączenie.
zxq9
0

Możesz wyłączyć blokadę dla poszczególnych udziałów w następujący sposób:

[acctdata]
oplocks = False
level2 oplocks = False

Domyślny typ blokady to Poziom1. Blokady poziomu 2 są włączane dla każdego udziału w pliku smb.conf. Alternatywnie możesz wyłączyć blokady na podstawie pliku w udziale:

veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/

Jeśli masz problemy z blokadami, jak wynika z wpisów w dzienniku Samby, możesz chcieć grać bezpiecznie i wyłączać blokady i blokady poziomu 2.

Wyłączanie blokad blokady jądra jest parametrem smb.conf, który powiadamia Sambę (jeśli jądro UNIX ma możliwość wysłania klientowi Windows przerwy w blokowaniu), gdy proces UNIX próbuje otworzyć buforowany plik. Ten parametr dotyczy udostępniania plików między UNIX a Windows z włączonymi oplockami na serwerze Samba: proces UNIX może otworzyć plik, który jest zablokowany (buforowany) przez klienta Windows, a proces smbd nie wyśle ​​przerwy oplock, co naraża plik na działanie ryzyko uszkodzenia danych. Jeśli jądro UNIX ma możliwość wysłania przerwy w blokowaniu, to parametr oplocks w jądrze umożliwia Sambie wysłanie przerwy w blokowaniu. Blokady jądra są włączane dla poszczególnych serwerów w pliku smb.conf.

kernel oplocks = yes

Domyślnie nie.

Źródło

ajcg
źródło