Bonjour,
Je me demande bien comment ce fichier à toute épreuve a fait son compte pour se retrouver dans un dossier dont le nom contient « non effaçables ».
Etant donné qu’il semble n’y être que sous forme fantôme, c’est une idée.
En fait il y a encore 2 jours il se trouvait sur mon PC de travail (Debian 11), sur lequel je n’arrivais pas à l’effacer quand j’y faisait le ménage.
Suite à cela, j’ai essayé ( et réussi) à déplacer le répertoire qui le contenait vers le NAS pour m’occuper de cela plus tard.
J’ai donc créé le rep : < /media/QRA_NAS/999_Fichiers_non_effacables>
et placé dedans le <Poub_2011_Motorola_Bea> avec son fichier « ineffaçable »
Puis (sur le NAS) j’ai essayé les « 1000 » variantes suggérées par les uns et les autres pour l’effacer
Je suppose que cela a du changer quelque-part un flag, car maintenant ce fichier et son répertoire ne peuvent plus être ni copié, ni déplacé, ni supprimé !
Voilà son « histoire » 
En résumé, c’est un fichier ineffaçable qui a été synchronisé avec le NAS.
Rien d’étonnant à ce qu’il reste ineffaçable dans le NAS.
Comme pour la Covid, il faut appliquer les gestes barrières.
Alors si je comprends le fichier est actuellement dans un dossier sur le nas …
Regarde le proprio du répertoire où est le dossier en question (opération à faire depuis le nas).
Si l’admin est propriétaire du répertoire tu ne doit sans doute pas avoir de droits à l’intérieur de supprimer des dossier/fichiers.
Vérifie que la corbeille réseau soit activé dans les paramètres de configuration du nas (vérification à faire depuis le nas).
Essai de le virer depuis ton poste en supprimant depuis le point de montage.
Vérifie que l’espace disque ne soit pas à 100% dans ton stockage sur ton nas (à vérifier depuis le nas).
Une fois vérifié connecte toi sur le nas en ssh et supprime le dossier à l’aide du compte root (attention à ne pas faire de blague à ce moment là).
P’têt bien 
Ultime tentative, est-ce que la commande lsattr voit quelque chose ?
Donc toutes les manipulations qui ne sont applicables qu’à un système de fichiers local (fsck, lsattr, inode…) ne fonctionnent pas depuis le client, il faudrait les faire depuis un shell directement sur le NAT (en SSH ou telnet).
Il ne me semble pas avoir vu passer le type de système de fichiers en réseau utilisé : NFS, SMB/CIFS (samba)… ainsi que de quelle façon il est monté (/etc/fstab, explorateur de fichiers…) avec quelles options… Ça pourrait avoir son importance.
Il me semble également d’après le message d’erreur que ce n’est pas la suppression (ou le déplacement, le renommage) qui échoue mais le nom du fichier qui n’est pas trouvé. Je soupçonne un possible bug lié aux caractères spéciaux (guillemets, espaces, €…) présents dans le nom du fichier, éventuellement lié aux encodages utilisés de part et d’autre (client et NAS) et à la conversion entre les deux.
Merci pour le « guidage »
-1- J’ai d’abord démonté le NAS de mon PC Debian (umount /media/QRA_NAS)
-2- Je me suis connecté au NAS par http://192.168.1.30/web/web_file/web_file_server.html
-3- J’ai utilisé le browser interne du NAS (DNS-320 Share Center by-D-link) pour accéder au répertoire 999_Fichiers_non_effacables/Poub_2011_Motorola_Bea
-4- J’ai pu supprimer le rep <999_xyz…> et son contenu avec.
-5- Déconnexion puis reboot, plus de trace du répertoire à supprimer
Je n’ai pas compris pourquoi ça n’a pas été possible à partir de mon PC et du point de montage du NAS. ?!
1 J'aime
Le NAS est monté au démarrage par la ligne /etc/fstab suivante
//192.168.1.30/Volume_1 /media/QRA_NAS cifs guest,iocharset=utf8,gid=100,uid=1000,_netdev,vers=1.0 0 0
Et, oui oui, c’est le nom du fichier lui-même qui était la source du problème.
Mais comme aucune commande de renommage n’avait fonctionné, j’étais resté coincé !
Et donc finalement, MERCI à tous, pour m’avoir finalement guidé vers la solution.
J’apprécie vraiment le temps que vous avez passé à vous occuper de mon truc !
1 J'aime
