Corruption fichiers via NFS

Bonjour à tous,

Je me heurte à un souci apparu il y a quelques semaines. Je suis sous testing sur mes deux ordis (millenium et Seaspeeder, pour la compréhension), et j’ai des partages nfs sur les /home. Le problème est le suivant: tout fichier lu à travers un montage nfs, ouvert depuis Seaspeeder, donne un message d’erreur. (Exemple, pour un pdf: Impossible d’ouvrir le document. Le type de fichier inconnu (application/octet-stream) n’est pas pris en charge). Idem pour un fichier copié sur le disque de Seaspeeder et ouvert sur celui-ci.
Par contre, quand je copie le document de Seaspeeder vers millenium, je le lis sans problème depuis millenium. Idem pour l’ouverture du document distant.
J’ai comparé les fichiers de config de nfs des deux ordis, ils sont identiques. Donc, je sèche sur l’origine du problème, et je ne trouve pas de pistes pour expliquer ça. Est-ce que quelqu’un aurait une piste de recherche à me proposer? Voire, mais j’abuse, un début de solution? Je peux vous poster ici tous les fichiers de conf, si cela était nécessaire.
Merci!

Dans un 1er temps : fsck

[quote]FSCK(8)

NOM
fsck - Vérifier et réparer un système de fichiers Linux
[/quote]

[mono]ntfsfix[/mono] : Réparation de problèmes communs des systèmes de fichiers NTFS

[quote] ntfsfix est un utilitaire en ligne de commande qui règle quelques-uns des problèmes les plus communs liés au système de fichiers NTFS. ntfsfix n’est pas un équivalent linuxien du chkdsk de Microsoft® Windows® ; il ne fait que réparer quelques inconsistances dans le système de fichiers NTFS, vide le fichier de journal de la partition et oblige Windows à vérifier l’intégrité du système de fichiers en question à l’amorçage suivant de Windows.

ntfsfix peut être utile si l’on pense que le système de fichiers NTFS a été endommagé et qu’il ne peut plus être monté. [/quote]

Mieux encore …

Nfs et nTfs, c’est pas pareil. Ntfs, système de fichiers microsoftien. Nfs, Network File System.
$ man -L fr fsck.nfs


NOM
       fsck.nfs - Script fsck.nfs vide et n'échouant jamais

SYNOPSIS
       fsck.nfs

DESCRIPTION
       A  été ajouté à Debian GNU/Linux pour le cas où le système de fichiers racine est de type NFS : il
       n'y a aucun moyen de deviner le système de fichiers et il  est  important  de  toujours  faire  un
       « fsck -a ».

CODE DE SORTIE
       Le code de sortie retourné par mount.nfs est toujours zéro, indiquant que tout s'est bien passé.

Tant qu’à lancer fsck, le lancer sur le système de fichiers local de préférence à une vérification sur le système de fichiers distant.
La vérification distante par fsck.nfs («tout s’est bien passé») ne saurait rien réparer.

[quote] J’ai comparé les fichiers de config de nfs des deux ordis, ils sont identiques.[/quote] Quels «fichiers de config» ? /etc/fstab ? /etc/exports ? Quels montages (commande [mono]mount[/mono]) ? Quel est le serveur ? Quel est le client ? Quels numéro IP ? Quels [mono]hostname[/mono]s ?
Se pinguent*-ils ?
*([mono]ping[/mono]uer: je [mono]ping[/mono]ue, tu [mono]ping[/mono]ues, elle [mono]ping[/mono]ue, nous [mono]ping[/mono]uons …)

Hum, je ne saurais dire pourquoi, j’ai lu [mono]nfs[/mono] et j’ai pensé [mono]ntfs[/mono], navré pour le bruit.

[quote=“etxeberrizahar”]quels «fichiers de config» ? /etc/fstab ? /etc/exports ? Quels montages (commande [mono]mount[/mono]) ? Quel est le serveur ? Quel est le client ? Quels numéro IP ? Quels [mono]hostname[/mono]s ?
Se pinguent*-ils ?
*([mono]ping[/mono]uer: je [mono]ping[/mono]ue, tu [mono]ping[/mono]ues, elle [mono]ping[/mono]ue, nous [mono]ping[/mono]uons …)[/quote]
Alors, on est en local, le partage marchait jusque là dans les deux sens (donc deux serveurs, mais là c’est le serveur sur Seaspeeder qui doit mettre la zone)
Le fichier de config, c’est /etc/export. Fstab n’est pas en cause, je passe par autofs pour le montage. Ceci dit j’ai testé le montage direct via mount en ligne de commande, même erreur. Et donc, si je transfère des fichiers, mes ordis se [mono]ping[/mono]uent bien… Il eut fallu un problème réseau pour qu’ils ne [mono]ping[/mono]uâte pas, ce qui ne semble pas être le cas :slightly_smiling: