Comment empêcher Samba de maintenir un verrou de fichier après la déconnexion d'un client?

Ici, j'ai un serveur Samba (Debian 5.0) qui est configuré pour héberger les profils Windows XP.

Les clients se connectent à ce serveur et travaillent sur leurs profils directement sur le partage samba (le profil n'est pas copié localement).

De temps en temps, un client peut ne pas s'arrêter correctement et donc Windows ne libère pas les verrous de fichiers. En regardant la table de verrouillage de samba, nous pouvons voir que de nombreux fichiers sont toujours verrouillés même si le client n'est plus connecté. Dans notre cas, cela semble se produire avec les fichiers de verrouillage créés par Mozilla Thunderbird et Firefox. Voici un exemple de la table de verrouillage 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

Nous pouvons voir que les fichiers ont été ouverts par Windows et ont imposé un verrou DENY_ALL.

Désormais, lorsqu'un client se reconnecte à ce partage et essaie d'ouvrir ces fichiers, samba dit qu'ils sont verrouillés et refuse l'accès.

Existe-t-il un moyen de contourner cette situation ou ai-je raté quelque chose?

Edit: Nous aimerions éviter de désactiver les verrous de fichiers sur le serveur samba car il y a de bonnes raisons de les activer.

les étapes ci-dessous m'ont aidé à résoudre ce problème exact à plusieurs reprises:

1. Connectez-vous au serveur samba.
2. Exécutez un "smbstatus".
3. Recherchez le pid du processus qui a le verrou sur le fichier dans la troisième section de la sortie.
4. Vérifiez qu'il correspond à l'utilisateur et au nom d'hôte attendus dans les première et deuxième sections de la sortie smbstatus.
5. Exécutez "ps -ef" et voyez depuis combien de temps le smbd avec ce pid fonctionne.
6. S'il a fonctionné depuis avant le dernier redémarrage de l'ordinateur, c'est un smbd restant. Tuez JUSTE QUE UN smbd. (Et assurez-vous que vous obtenez le bon - il devrait être celui qui a un pid parent différent de 1.)

Jettes un coup d'oeil à:

reset on zero vc = yes / no

et voyez si cela résoudra votre problème ou non.

Depuis la smb.confpage de manuel:

Cette option booléenne contrôle si une configuration de session entrante doit tuer les autres connexions provenant de la même IP. Cela correspond au comportement par défaut de Windows 2003. La définition de ce paramètre sur oui devient nécessaire lorsque vous avez un réseau instable et que Windows décide de se reconnecter alors que l'ancienne connexion a toujours des fichiers avec des modes de partage ouverts. Ces fichiers deviennent inaccessibles sur la nouvelle connexion. Le client envoie un VC nul sur la nouvelle connexion et Windows 2003 tue toutes les autres connexions provenant de la même IP. De cette façon, les fichiers verrouillés sont à nouveau accessibles. Veuillez noter que l'activation de cette option supprimera les connexions derrière un routeur de masquage.

Edit :
je viens de réfléchir à une autre solution possible. Vous pouvez faire quelque chose comme ça sur le partage en question.

veto oplock files = /*.lock/

Cela empêcherait simplement les oplocks sur les fichiers .lock.

Certaines personnes très intelligentes chez Samba ont décidé de supprimer cette option et il n'y a pas de remplacement pour elle.

Jusqu'à présent pour la compatibilité SMB, car il s'agit en effet d'un comportement gagnant par défaut.

À moins qu'un utilisateur ne connaisse la ligne de commande Linux et comment tuer les fichiers / processus ouverts, vous devez redémarrer SMBD ou le serveur lui-même pour effacer cela.

Merveilleusement fait, Samba.org.

Je rencontrais un problème similaire, un client s'est écrasé lors de la copie d'un fichier volumineux et le fichier a été verrouillé après le redémarrage. Heureusement, cela ne se produit pas très souvent, mais c'est quand même assez ennuyeux de devoir tuer le processus de samba. reset on zero vcsemblait être juste la solution, mais il est censé avoir été supprimé de Samba4, bien que la version 4.7.6 sur Fedora (27) l'ait toujours (éventuellement corrigé par RH). De toute façon, comme le dit la page de manuel, cela n'aidera pas beaucoup, car cela ne fonctionne qu'avec SMB1 (qui ne devrait plus être utilisé) et ne fait rien sur les connexions SMB2 et SMB3, la seule façon de gérer cela est mentionnée dans le fil lié par Micheal . Je ne connais pas la justification de la suppression et ce qui est si mauvaisreset on zero vc, J'envisagerais d'utiliser le délai d'attente tcp à cette fin plus comme un hack. Quoi qu'il en soit, quelque chose de raisonnable pourrait être par exemple

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

Cela tuera la connexion environ 40 secondes (30 + 3 * 3) après la dernière communication, ce qui est généralement plus que suffisant pour remarquer un crash et un redémarrage (étant donné que la pile TCP du serveur est suffisamment intelligente pour fermer la connexion lorsque le client rejette ses paquets keepalive après le redémarrage).

Notez que cela augmente la charge sur votre réseau, mais je doute que cela soit même perceptible même avec de nombreux clients.

Vous pouvez désactiver les oplocks par partage avec les éléments suivants:

[acctdata]
oplocks = False
level2 oplocks = False

Le type d'oplock par défaut est Level1. Les oplocks de niveau 2 sont activés par partage dans le fichier smb.conf. Alternativement, vous pouvez désactiver les oplocks par fichier dans le partage:

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

Si vous rencontrez des problèmes avec les oplocks, comme le montrent les entrées du journal de Samba, vous pouvez vouloir jouer en toute sécurité et désactiver les oplocks et les oplocks de niveau 2.

Désactivation des Oplocks du noyau Les oplocks du noyau sont un paramètre smb.conf qui notifie Samba (si le noyau UNIX a la capacité d'envoyer à un client Windows une pause oplock) lorsqu'un processus UNIX tente d'ouvrir le fichier mis en cache. Ce paramètre concerne le partage de fichiers entre UNIX et Windows avec les oplocks activés sur le serveur Samba: le processus UNIX peut ouvrir le fichier qui est Oplocked (mis en cache) par le client Windows et le processus smbd n'enverra pas de pause oplock, ce qui expose le fichier à le risque de corruption des données. Si le noyau UNIX a la capacité d'envoyer une interruption oplock, le paramètre oplocks du noyau permet à Samba d'envoyer l'interruption oplock. Les oplocks du noyau sont activés par serveur dans le fichier smb.conf.

kernel oplocks = yes

La valeur par défaut est non.

La source