Come impedire a samba di trattenere un blocco di file dopo la disconnessione di un client?

11

Qui ho un server Samba (Debian 5.0) configurato per ospitare i profili di Windows XP.

I client si connettono a questo server e lavorano sui loro profili direttamente sulla condivisione samba (il profilo non viene copiato localmente).

Di tanto in tanto, un client potrebbe non arrestarsi correttamente e quindi Windows non libera i blocchi dei file. Guardando la tabella di blocco di samba, possiamo vedere che molti file sono ancora bloccati anche se il client non è più connesso. Nel nostro caso, questo sembra accadere con i file di lock creati da Mozilla Thunderbird e Firefox. Ecco un esempio della tabella di blocco samba:

# 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

Possiamo vedere che i file sono stati aperti da Windows e hanno imposto un blocco DENY_ALL.

Ora quando un client si riconnette a questa condivisione e prova ad aprire quei file, samba dice che sono bloccati e nega l'accesso.

C'è un modo per aggirare questa situazione o mi sto perdendo qualcosa?

Modifica: vorremmo evitare di disabilitare i blocchi dei file sul server samba perché ci sono buoni motivi per abilitarli.

linux samba server-message-block

— Jean-Francois Chevrette
fonte

11

i passaggi seguenti mi hanno aiutato a risolvere questo problema esatto in diverse occasioni:

Accedi al server samba.
Esegui un "smbstatus".
Trova il pid del processo che ha il blocco sul file nella terza sezione dell'output.
Verificare che corrisponda all'utente previsto e al nome host nella prima e nella seconda sezione dell'output di smbstatus.
Esegui "ps -ef" e vedi da quanto tempo è in esecuzione lo smbd con quel pid.
Se è in esecuzione da prima dell'ultimo riavvio del computer, è un smbd rimasto. Uccidi SOLO QUELLO smbd. (E assicurati di ottenere quello giusto - dovrebbe essere uno che ha un pid genitore non uguale a 1.)

— Socceroos
fonte

Inoltre, potresti scoprire che alcuni pid di smbd sono in esecuzione da alcune ore e che i file che hanno bloccato sono quelli che ti servono. Come sopra, basta uccidere questi processi e dovresti stare bene. Se si elimina inavvertitamente il processo smbd principale, è possibile riavviarlo con questo comando: sudo /etc/init.d/smbd restart

— Socceroos,

5

Dai un'occhiata a:

reset on zero vc = yes / no

e vedere se questo risolverà il tuo problema o no.

Dalla smb.confpagina man:

Questa opzione booleana controlla se un'impostazione della sessione in entrata deve uccidere altre connessioni provenienti dallo stesso IP. Ciò corrisponde al comportamento predefinito di Windows 2003. L'impostazione di questo parametro su yes diventa necessaria quando si dispone di una rete instabile e Windows decide di riconnettersi mentre la vecchia connessione ha ancora file con modalità di condivisione aperte. Questi file diventano inaccessibili con la nuova connessione. Il client invia un VC zero sulla nuova connessione e Windows 2003 uccide tutte le altre connessioni provenienti dallo stesso IP. In questo modo i file bloccati sono nuovamente accessibili. Si noti che abilitando questa opzione si interromperanno le connessioni dietro un router mascherato.

Modifica :
ho appena pensato ad un'altra possibile soluzione. Puoi fare qualcosa del genere sulla condivisione in questione.

veto oplock files = /*.lock/

Ciò impedirebbe solo gli oplock sui file .lock.

— 3dinfluence
fonte

0

Alcune persone molto intelligenti di Samba hanno deciso di rimuovere questa opzione e non vi è alcun sostituto per essa.

Finora per la compatibilità delle PMI quindi, poiché si tratta in effetti di un comportamento di vincita predefinito.

A meno che un utente non sia esperto nella riga di comando di Linux e su come uccidere file / processi aperti, è necessario riavviare SMBD o il server stesso per cancellarlo.

Fatto meravigliosamente, Samba.org.

— Michael
fonte

Hai una citazione per questo?

— BE77Y,

Dovrai dare un'occhiata ad alcuni per arrivarci, ma: lists.samba.org/archive/samba-technical/2011-July/078621.html (mostra il processo di pensiero e chap che chiedono che non venga rimosso) elenchi .samba.org / archive / samba-technical / 2008-October /… (mostra che il parametro è stato rimosso in 4.0)

— Michael

A partire dal 2019, in Debian 9 - Samba 4.5.12, l' reset on zero vcopzione è ancora elencata nel manuale e visualizzata anche da testparm. Quindi o è tornato o non è stato rimosso.

— marzo

0

Stavo riscontrando un problema simile, un client si è bloccato durante la copia di un file di grandi dimensioni e il file è stato bloccato dopo il riavvio. Fortunatamente questo non accade molto spesso, ma è comunque abbastanza fastidioso dover uccidere il processo di samba. reset on zero vcsembrava essere solo la soluzione, ma è presumibilmente rimosso da Samba4, sebbene la versione 4.7.6 su Fedora (27) lo abbia ancora (probabilmente patchato da RH). In ogni caso, non sarà di grande aiuto, come dice ora la pagina man, che funziona solo con SMB1 (che non dovrebbe più essere usato) e non fa nulla su connessioni SMB2 e SMB3, l'unico modo rimasto per gestirlo è menzionato in il thread collegato da Micheal . Non conosco la logica alla base della rimozione e cosa c'è di così bruttoreset on zero vc, Considererei l'utilizzo del timeout di TCPC per questo scopo più come un hack. Comunque qualcosa di ragionevole potrebbe essere ad es

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

Ciò interromperà la connessione circa 40 secondi (30 + 3 * 3) dopo l'ultima comunicazione, che di solito è più che sufficiente per notare un arresto anomalo e il riavvio (dato che lo stack tcp del server è abbastanza intelligente da chiudere la connessione quando il client rifiuta i suoi pacchetti keepalive dopo il riavvio).

Nota che questo aumenta il carico sulla tua rete, ma dubito che sia persino evidente anche con molti client.

— Jakob
fonte

Sai se questo aiuta con il bizzarro problema del thread zombie "nessuno nogroup" del client Windows10? Molti dei miei client Windows 10 in diversi siti hanno iniziato a lasciare centinaia (a volte migliaia) di thread di zombi che vengono assegnati a "nessuno nogroup" fino a quando il loro processo di gestione non viene interrotto / ritirato. Normalmente l'impostazione deadtime = 10o giù di lì lo cancellerebbe, ma con i blocchi di file che persistono sulle connessioni SMB3_11 per sempre non ha alcun effetto, poiché i tempi morti non verranno controllati mentre esistono ancora i filelock per un PID. Estremamente frustrante.

— zxq9,

Non ho mai sentito parlare o riscontrato il problema che descrivi. deadtimenon fa nulla se i tuoi client hanno file aperti, quindi la domanda sarebbe: quali file mantengono aperti. Ma questo è probabilmente un problema completamente diverso da quello discusso qui, quindi dovresti aprire una nuova domanda per questo. Il mio socket optionssuggerimento aiuta solo con connessioni che non sono correttamente chiuse (perché i client si arrestano in modo anomalo, un'interruzione della rete, ecc.), Ma probabilmente non se i client WX si connettono al server senza ulteriori azioni o utilizzando una sorta di sessione anonima (che nobody.nogroupsuggerisce ).

— Jakob

Sembra esserci una domanda su questo problema, ma senza una soluzione reale. Sembra che potrebbe essere un problema di samba che potrebbe essere risolto in una versione più recente.

— Jakob

Ci sono parecchie menzioni di questo sulla mailing list, nessuna soluzione reale presentata da nessuna parte, e nessuna versione che ho provato (ogni ramo attuale tranne 4.9) risolve il problema. È solo con client Windows10. Il nessuno: la cosa del nogroup è sconcertante, poiché gli ospiti sono disabilitati a livello globale, nessuna condivisione li accetta e il PID delle voci nessuno è sempre lo stesso di una singola voce valida con un nome utente valido. Quindi vedi 12345 someuser somegroup...una voce, quindi 800 12345 nobody nogroup ...voci, ma solo una manciata di blocchi di file (non 800). Molto strano. Ora interessa 3 dei siti dei miei clienti.

— zxq9

Questo diventa solo un vincolo di risorse sui siti ad alta attività, motivo per cui penso che riceva così poca attenzione. Il più delle volte non c'è un problema, quindi le persone non se ne accorgono e in qualche modo si risolve da sé ogni volta che i client chiudono effettivamente la loro connessione.

— zxq9

0

È possibile disabilitare gli oplock in base alla condivisione con quanto segue:

[acctdata]
oplocks = False
level2 oplocks = False

Il tipo di oplock predefinito è Level1. Gli oplock di Level2 sono abilitati su base per condivisione nel file smb.conf. In alternativa, è possibile disabilitare gli oplock in base al file all'interno della condivisione:

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

Se riscontri problemi con gli oplock, come risulta dalle voci di registro di Samba, potresti voler giocare in sicurezza e disabilitare gli oplock e gli oplock di Livello2.

Disabilitazione degli oplock del kernel Gli oplock del kernel sono un parametro smb.conf che notifica a Samba (se il kernel UNIX ha la capacità di inviare a un client Windows un'interruzione di oplock) quando un processo UNIX sta tentando di aprire il file memorizzato nella cache. Questo parametro risolve la condivisione di file tra UNIX e Windows con gli oplock abilitati sul server Samba: il processo UNIX può aprire il file Oplocked (memorizzato nella cache) dal client Windows e il processo smbd non invierà un'interruzione oplock, che espone il file a il rischio di corruzione dei dati. Se il kernel UNIX ha la capacità di inviare un'interruzione di oplock, il parametro oplocks del kernel consente a Samba di inviare l'interruzione di oplock. Gli oplock del kernel sono abilitati su base per server nel file smb.conf.

kernel oplocks = yes

L'impostazione predefinita è no.

fonte

— AJCG
fonte