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

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 są dobre powody, aby mieć te włączone.

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.)

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.

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.

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.

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