OpenOffice + NFS

Quand on ne sait pas, ce couple donne mal à la tête.

J’ai eu à faire un partage NFS entre 2 machines gnu/linux, l’une (client) sous archlinux, l’autre (serveur) sous ubuntu.
NFS était installé sur les 2 machines, il suffisait de rajouter le répertoire qui va bien dans /etc/exports tout en vérifiant si les droits sont suffisants pour y accèder:

/home/export ip_ou_nom_du_client(async)

Puis de redémarrer le serveur, sous ubuntu:

/etc/init.d/nfs-user-server restart

(j’ai pas fait attention au nom du daemon, les joies de la complétion avec TAB)

Et là, plus qu’à monter le répertoire sur le client:

mount ip_ou_nom_du_serveur:/home/export /mnt/export

Mais… ca ne fonctionne pas! Une erreur au bout d’1mn, impossible de créer les locks, il faut démarrer le service nfslock:

/etc/rc.d/portmap start
/etc/rc.d/nfslock start

Je retente… bien, ca fonctionne, je lance un document OpenOffice, l’image splash apparait… et reste :/

Et la, débute mon incompréhension, et comme un c** je ne fais pas de requête sur le net pensant à une erreur de ma part (quoique, un peu).

Après un début de migraine que j’aurais très bien pu éviter, on trouve facilement sur le net, qu’en fait, OpenOffice a besoin de mettre un verrou sur le fichier, mais n’affiche aucune erreur s’il n’y arrive pas.
Ceci dit, pourquoi il n’y arrive pas; tout simplement à cause du daemon NFS (nfs-user-server) installé sur le serveur qui est en fait un daemon qui se lance dans l’espace utilisateur et ne gère pas les verrous (entre autres).

Donc la solution était de changer de serveur en installant nfs-kernel-server ou tout simplement monter le partage sans les verrous (ce qui évite de lancer le daemon portmap et nfslock sur le client):

mount ip_ou_nom_du_serveur:/home/export /mnt/export -o nolock

On peut aussi désactiver la demande de verrou depuis OpenOffice en modifiant le script /usr/bin/soffice en mettant la variable SAL_ENABLE_FILE_LOCKING à 0.

Bon là, ca va mieux…