Erreur lors de l’opération de « splicing » sur le fichier : Erreur d'entrée/sortie (debian 10)

Support Debian
#1

Bonjour,

J’ai installé une Debian 10 et j’ai un certain nombre de disques réseaux à monter et je fais ça habituellement avec une intallation de samba et mount-cifs. Ça marche bien depuis des années. Là j’ai rencontré un pb : la nouvell version de mount-cifs a pour option par défaut vers=3.0 alors que précédemment c’était 1.0. Spécifier vers=1.0 au montage rétabli le fonctionnement antérieur.

Le pb est généré de la façon suivante. Dans la moitié gauche de mon écran nautilus sur un disque réseau dans le répertoire X. Dans la moitié droite de mon écran le même disque dans le répertoire Y. Je drag and drop un fichier de l’un à l’autre avec CTRL d’enfoncé pour faire une copie et cela génère l’erreur
Erreur lors de l’opération de « splicing » sur le fichier : Erreur d’entrée/sortie

Merci d’avance pour toute aide.
@+

EDIT 00 je me suis sorti du pb de copie avec une debian 9 sur laquelle ça marche sans pb. C’est d’ailleurs une solution au pb : installer une debian 9 au lieu d’une 10.

#2

Alors ça, dans l’absolu, c’est juste un fait, pas un problème.
En quoi est ce un problème, et en quoi est ce lié au message “splicing” dans nautilus dont tu parles aprés ?

Ben utiliser cp plutot que nautilus pour faire des copies me semble une solution moins contraignante qu’une reinstall, mais bon.
Mais vu que ton soucis semble être sur nautilus, tu as essayé d’utiliser un autre gestionnaire de fichier ou la version sid de gnome ?

#3

Pardon les infos sont arrivées dans le désordre. Ça marche depuis des années avec successivement du xubuntu 10.04, 14.04 et debian 9 et là en passant sur debian 10 patatra. Ainsi je donne l’info parce que le passage à debian 10 a déjà coincé et je ne sais pas dans quelle mesure autre chose peut être liée à ce que j’ai déjà relevé, à la cause qui a induit le changement de valeur par défaut de “vers” de 1.0 à 3.0. Autrement dit, je ne sais pas dans quelle mesure ce changement dans mount-cifs est aussi responsable du pb de slicing, peut être à régler avec une autre option ?

Pour ce qui est de réinstall, chacun voit midi à sa porte, perso je préfère passer 1 jour pour avoir un système qui correspond à la manière dont je travaille plutôt que d’utiliser cp (les architectures de fichiers que j’utilise sont un peu labyrinthiques, c’est plus simple d’opérer visuellement). Par ailleurs, le pb relevé est un symptôme, il y a peut être d’autres pbs à venir.

J’ai fait un peu de recherche des causes imaginées pour l’erreur que j’évoque, je relève 1) le HDD est en fin de vie 2) j’ai un rapport de bug qui ressemble à ce que je relève. Pour 1) j’y crois pas trop. Pour 2), j’ai pas eu le temps de creuser.

Merci de ta réponse.
@+

#4

Nan, mais jeter le bébé avec l’eau du bain et reinstaller sans même tester pour voir si le cp passe ou un autre gestionnaire de fichier, c’est un peu bourrin quand même.

Et donc, si les suggestions qu’on te fait vont forcément contre tes convictions, tu viens nous demander quoi du coup ?

#5

salut
quand j’ai vu ça j’ai toujorus diagnostiqué fin de vie du disque dur.
si tu crois que ça vient d’une version d’un paquet, alors ça m’intéresserait de le savoir.
Comment savoir :
1.crée une clé de boot avec l’ancinen version
2.testes

#6

Hello,
cp n’est pas une résolution du pb mais un contournement ou au mieux un test, je le ferais, mais à long terme je ne peux pas envisager de faire mes copies à coup de cp.

Ce qui est troublant c’est qu’en debian9 pas de pb et en debian10 => pb. Et on sait que quelque chose a changé coté samba/mount-cifs. Quelque chose que je pourrais tester c’est voir si le même pb est rencontré si je monte le volume réseau dans nautilus plutôt qu’avec fstab. En fait je n’ai vraiment besoin qu’un seul de mes volumes réseau soit monté avec fstab. Mais cela règle pas le pb pour ce volume.

dindoun> le pb pour faire le test que tu suggères : faire une live-usb avec une debian 9 pas de pb, mais il faut que modifie le fstab et là je ne vois pas trop comment faire …

Je ne peux pas passer plus de temps sur ce pb immédiatement mais j’y reviendrais.
Merci à tout le deux
@+

#7

Bonne année.
Des news.

  1. sur le portable maison : je fais une sauvegarde sur disque dur externe (fat32 de tête), je réinstalle une debian sur le portable, je vais pour restaurer les fichiers depuis le disque dur externe => error splicing sur un fichier de 4.3 GO.
  2. aujourd’hui sur la machine bureau (debian10) pour laquelle j’ai posté la première fois ici dans ce fil, depuis une clé USB vers un répertoire réseau => splicing error …

voir si le même pb est rencontré si je monte le volume réseau dans nautilus plutôt qu’avec fstab

J’ai fait un essai en montant 2 répertoires réseaux (même serveur) dans nautilus avec smb:// et là il n’y a pas de pb. Donc le pb viens d’un montage smb+cifs

@+

#8

ça a surtout à voir avec la version de windows avec laquelle tu veux partager

https://manpages.debian.org/stretch/cifs-utils/mount.cifs.8.en.html

vers=

SMB protocol version. Allowed values are:

•1.0 - The classic CIFS/SMBv1 protocol. This is the default.

•2.0 - The SMBv2.002 protocol. This was initially introduced in Windows Vista Service Pack 1, and Windows Server 2008. Note that the initial release version of Windows Vista spoke a slightly different dialect (2.000) that is not supported.

•2.1 - The SMBv2.1 protocol that was introduced in Microsoft Windows 7 and Windows Server 2008R2.

•3.0 - The SMBv3.0 protocol that was introduced in Microsoft Windows 8 and Windows Server 2012.
#9

Yes grandtoubab mais j’ai déjà signalé ce point et en particulier que la version mount-cifs de debian 10 à pour option par défaut vers=3.0 alors que précédemment c’était vers=1.0. En 3.0 les volumes réseaux étaient même pas montés et j’avais des messages d’erreur je crois (genre j’avais pas les droits, mais je ne me souviens plus très bien) donc je suis déjà passé en vers=1.0 et là les volumes se montent mais j’ai ce pb de splicing. Un collègue a trouvé qu’il y avait un pb (un bug) avec les noyaux 4.9 … Je donne la ref quand je l’ai.
Merci
@+

EDIT 00 : ma debian 9 possède le noyau 4.9.0-11-amd64 (x86_64). Je comprends que buster est en 4.19 : c’est sans doute ce dernier noyau qui pose PB.

#10

Rien n’empêche d’installer/tester un noyau 4.9 sur la buster.

#11

Bonjour,

J’ai dégagé une demi heure pour faire un test formel. “Protocole” :

  1. j’installe une ubuntu 18.04
  2. je faire un apt update apt upgrade apt full-upgrade
  3. j’installe samba et cifs-utils
  4. je modifie hosts, fstab et .smbcredentials pour accéder à mes volumes réseaux
  5. reboot
  6. soit 2 volumes réseaux, au demeurant sur le même disque, mettons //disque/dir1 et //disque/dir2, avec 2 nautilus je fais la copie du premier vers le second d’un pptx de 2.0 Mo

=> Erreur lors de l’opération de « splicing » sur le fichier : Erreur d’entrée/sortie

Notes :

  1. à la mise à jour de la 18.04 j’ai vu passer rapidement l’installation d’un noyau 5.0, ce que uname -r m’a confirmé (5.0.0-37 generic)
  2. dans fstab pour pouvoir accède à mes volumes réseaux il faut toujours que je spécifie vers=1.0 en option

Suite
J’essaie avec cp

  1. j’ai un message d’erreur “erreur d’écriture dans … : mauvaise adresse” mais le fichier est créé il fait 2.1 Mo au lieu de 2.0 Mo mais à l’ouverture avec libreoffice, il me dit qu’il est corrompu qu’il peut le réparer mais finalement la réparation ne marche pas.
  2. j’ai un autre fichier, un *.sql (2.2ko) dont ne nom ne contient pas d’accents non plus que d’espace (ce qui est était le cas du pptx) : aucun pb
  3. je vais pour faire une copie du pptx dans le répertoire d’origine en changeant son nom pour virer les accents et espaces => mauvaise adresse. J’ouvre le pptx dans libreoffice je le sauvegarde sous coucou.pptx, je tente une copie de dir1 vers dir2 : mauvaise adresse … donc ce n’est pas un pb de nom …

Avec libre office j’ouvre un nouveau document writer, j’enregistre la page blanche sous “Sans nom.odt” (7.7ko) je le copie de dir1 vers dir2 avec les fenêtres nautilus => no pb. J’ajoute un accent dans le nom du fichier => no pb … Avec cp => no pb.

Je m’oriente vers l’instalation d’une debian 9 sans carte réseau, le téléchargement du pilote de la carte réseau (I219-LM), la compilation du pilote et installation. Je crois que la difficulté consiste à compiler sur le système utilisateur, or j’ai cru comprendre kkpart qu’une installation n’a pas de make, et ainsi qu’il faut faire la manip dans une virtualbox …

@+

#12

Bonjour,

Hier soir :

=> ok la carte ethernet fonctionne

Ce matin :

  • modification hosts, fstab et .smbcredentials
  • reboot et reprise du protocole de copie ci-dessus

=> aucun pb de copie dès le premier pptx avec ses accents et espaces.

Par voie de conséquence (et attendu que coté serveur de fichier aucun changement n’est intervenu) il y a bien un changement qui est intervenu entre le noyau 4.9 et le 4.19+ qui fait qu’un truc qui marchait avant ne marche plus (où est le changement ??? noyau, samba, cifs-utils autre ?)

Dans l’immédiat en ce qui me concerne, le fait d’avoir monté une debian 9 sur ce latitude 5500 à d’autres effets secondaires : pas de pilote wifi, pas de son, pas de réglage de la luminosité, touchpad à minima (pas de 2 doigt, pas de défilement sur les bords, pas de bluetoothn bref pas grand chose mais tout n’est ps essentiel). Pour le pilote wifi je pensais que je pourrais m’en tirer comme pour la carte ethernet, sauf que je n’ai pas encore trouvé le pilote et que du coup je ne suis pas sûr qu’il soit dispo, ce que j’ai compris c’est que ça venait plutôt avec le noyau.

Pour ce qui est du pb que je mets en évidence : j’imagine que ça serait bien si je faisais remonter le bug. Je n’ai pas d’expérience en la matière.

@+

#13

Un lien intéressant proposant des choses à tester au montage CIFS :


cache=none ou rsize=16384

Copie de nombreux fichiers plante
#14

BINGO !
un montage avec vers=1.0 et rsize=16384 permet de faire la copie du pptx sans erreur et le fichier à l’arrivée n’est pas corrompu.
Fin de l’histoire pour moi (jusqu’au prochain pb … )
Merci
@+