C'est un vieux problème très courant: vous avez un partage en réseaux quelconque, avec des utilisateurs qui vont et viennent joyeusement ouvrir, lire et modifier des documents, quand soudain, c'est le drame:

Un fichier est bloqué en lecture seule !

Et ce n'est pas faute à Samba, mais à la gestion des “verrous” par fichiers mis en place par Micro$oft.

J'ai eu beau chercher sur les Internets , mais les solutions que j'ai trouvé pour ce “problème” sont d'une vacuité terrible:

• Soit il faut effacer un petit fichier “~…” qui fait “office” de verrou.
• Soit il faut fermer la session de l'utilisateur fautif à la main.

( Si vous voulez un petit mal de tête, la solution “définitive” approuvé par Micro$oft est là )

Quand on doit faire ça 1 fois de temps en temps, c'est possible… Mais pas plusieurs fois par jour , Naaaan

Donc, je vais proposer ma petite solution…

~~READMORE~~

A la base, si un fichier est bloqué, c'est parce qu'un utilisateur (du partage) l'a ouvert pour son usage exclusif.

Au bout d'un moment, l'utilisateur devrait fermer le fichier pour que d'autres puissent l'ouvrir ensuite…

Mais parfois, surtout lorsque l'utilisateur est “nomade” (sur un VPN en GSM ou Wifi), l'utilisateur perd la communication avec le partage sans avoir eu le temps de fermer la session et de “libérer” le fichier .

Et c'est là le drame: le fichier reste bloqué alors que l'utilisateur n'est plus là.

Ma solution part du principe, simple et évident, qu'une session doit être terminée, de force si nécessaire, dés que le serveur a perdu la communication avec son correspondant.

Dans le protocole TCP/IP, ce mécanisme existe déjà et s'appelle Keepalive, mais il n'est pas mis en œuvre par défaut par Samba, et puis les temps d'attente par défauts sont trop long.

Pour activer le protocol “Keepalive”, il faut d'abord modifier les paramètres de création de socket en ajoutant le drapeau “SO_KEEPALIVE”.

Par exemple, dans “/etc/samba/smb.conf”, dans la section “[global]”, on peut ajouter ça:

   socket options = TCP_NODELAY SO_KEEPALIVE

( Vérifier la configuration avec la commande “testparm -v -s” )

Redémarrer “Samba” pour que la modification soit appliquée:

# /etc/init.d/samba restart

Maintenant, on va modifier les délais d'attente du protocole “Keepalive”, car par défaut, ils sont trop long: 2 heures !

Je vais réduire à 10 minutes maximum.

Pour que la modification soit persistante dans le temps (et les reboots), je vais définir les nouvelles valeurs dans le fichier
“/etc/sysctl.d/local.conf” .

Et j'y ajoute:

# ------------------------
# keepalive pour Samba
# Si pas de reponse apres 480 s + 20s * 6
net.ipv4.tcp_keepalive_time = 480
net.ipv4.tcp_keepalive_intvl = 20
net.ipv4.tcp_keepalive_probes = 6
# ------------------------

On applique immédiatement ces valeurs:

# sysctl -p /etc/sysctl.d/local.conf

Dernière remarque: Ne réduisez pas trop ce delai (“tcp_keepalive_time”) car vous risquez de surcharger inutilement le réseau et de produire des faux positifs.

Voici quelques fausses pistes que j'avais exploré dans “Samba”:

Il existe une option “keepalive” dans Samba.

En théorie, ça devrait faire la même chose que la solution que j'ai donné plus haut, mais en pratique non, parce que ça ne s'applique qu'au protocole “SMB1”.
Le protocole “SMB1” est totalement obsolète et globalement inutilisé, et lorsqu'il n'est pas désactivé, il peut devenir un vecteur de nombreuses failles de sécurité !

L'option “deadtime” sert simplement a fermer la session, après un certain délai, si aucun fichier n'est ouvert…
Donc, ça ne nous aidera pas pour les fichiers ouverts et “bloqués”.

Ma solution fonctionne

On n'évitera pas les boulets, mais au moins le système s' auto-réparera en cas d'incidents de communications.

Voila.