zigobs

Je n'avais pas cliqué sur la petite flèche pour déplier "usbshare1". En faisant cela j'ai pu accéder au contenu du disque dur USB (mais en cliquant sur "usbshare1" l'erreur E/S est toujours présente. Et bien qu'USB Copy ait annoncé une erreur (code d'erreur -10) tous les fichiers et dossier ont bien été copiés depuis le NAS vers le disque dur externe (au bit près, j'ai vérifié). En résumé : USB Copy annonce une erreur, si on clique sur "usbshare1" on obtient une erreur E/S mais malgré tout la copie s'est parfaitement déroulée. Difficile dans ces conditions d'utiliser sereinement USB Copy...

Bonjour, Nom de modèle : RS3617xs+ Version actuelle de DSM : DSM 7.2-64570 Update 1 J'ai connecté un premier disque dur externe USB (NTFS) afin d'y copier des données depuis le NAS en créant une tâche USB Copy (un peu moins d'1 To). La copie s'est correctement déroulée pendant une vingtaine de minute puis une erreur s'est produite : "La tâche a rencontré des erreurs inconnues. Dernier code d'erreur : -10 (Erreur d'opération de fichiers dossiers)" Bon, peut-être un problème avec le disque dur externe USB... J'ai donc supprimé la tâche et retiré physiquement le disque qui était démonté suite à l'arrêt de la tâche. J'ai ensuite recommencé exactement la même opération avec un autre disque dur externe USB (NTFS), et paf même erreur (mais au bout de quelques minutes seulement)... Pour cette nouvelle tâche j'avais demandé à ce que le disque ne soit pas démonté à la fin de l'opération, histoire d'aller voir dedans avec l'explorateur "File station". J'ai donc cliqué sur "usbshare1" dans "File station" mais à la place du contenu du disque (panneau de droite) j'ai un message : "Une erreur E/S s'est produite. Réessayez ultérieurement". J'ai déjà fait quelques transferts avec USB Copy il y a quelques mois sans problème, .les deux disques durs externes USB utilisés sont quasi neufs et de modèles totalement différents, j'en déduis que le problème ne vient pas des disques durs externes mais bien du NAS. Quelqu'un a-t-il rencontré ce problème ? Avez-vous pu le résoudre ? Merci pour votre aide. Bonne soirée.

C'est un patch écrit spécialement pour ce bug. Il m'a proposé d'appliquer le patch avec une prise en main à distance sur mon poste de travail (Mon NAS n'est accessible que depuis notre réseau interne). Mais n'ayant pas besoin de corbeille dans ce cas précis j'attendrai tranquillement DSM 7.2 Bonne journée.

Bonjour, Et pour clore définitivement l'affaire voilà un complément de réponse de Synology : Il s'agit donc bien d'un bug qui sera corrigé dans la version DSM 7.2... Bonne journée.

Bonjour, Le support Synology a résolu le problème. Pour info c'est le fait d'activer la corbeille sur les dossiers partagés du NAS qui crée ce problème. Sans corbeille pas de problème pour supprimer les dossiers. Voilà un extrait des logs : 2023-01-23T17:24:59+01:00 Arcad_Syn internal-sftp[26465]: recycle_unlink.c:349 Path(share=/volume1/TEST, rpath=projet-test/folder-test) is not a file. 2023-01-23T17:24:59+01:00 Arcad_Syn internal-sftp[26465]: sftp-server.c:1657 SYNORecycleUnlinkFileWithSharePath failed. share_path:[/volume1/TEST] rpath:[projet-test/folder-test] [0x0D00 recycle_unlink.c:350] 2023-01-23T17:24:59+01:00 Arcad_Syn internal-sftp[26465]: recycle_unlink.c:349 Path(share=/volume1/TEST, rpath=projet-test/folder-test) is not a file. 2023-01-23T17:24:59+01:00 Arcad_Syn internal-sftp[26465]: sftp-server.c:1657 SYNORecycleUnlinkFileWithSharePath failed. share_path:[/volume1/TEST] rpath:[projet-test/folder-test] [0x0D00 recycle_unlink.c:350] 2023-01-23T17:24:59+01:00 Arcad_Syn internal-sftp[26465]: recycle_unlink.c:349 Path(share=/volume1/TEST, rpath=projet-test/folder-test) is not a file. 2023-01-23T17:24:59+01:00 Arcad_Syn internal-sftp[26465]: sftp-server.c:1657 SYNORecycleUnlinkFileWithSharePath failed. share_path:[/volume1/TEST] rpath:[projet-test/folder-test] [0x0D00 recycle_unlink.c:350] J'ai demandé au support si c'est un bug ou le comportement normal, à suivre... Bonne journée.

Oui, ça fait plusieurs années que je n'ai pas été coincé comme ça après une enquête aussi poussée... Néanmoins tout ramène au NAS et ce qui m'inquiète le plus c'est d'être le seul (apparemment) à rencontrer ce problème. Bon, j'ai encore une ou deux cartouches : notamment examiner les logs du NAS de manière plus poussée. Là j'ai juste vu ce que me donne l'interface graphique alors qu'habituellement je passe du temps dans les logs des mes serveurs Debian pour diagnostiquer les problèmes. Je connais moins bien DSM mais il y a sans doute les logs du serveur SFTP accessibles quelque part en ligne de commande, après tout c'est du Linux... Il y a aussi l'option de redémarrer le NAS ou de faire les dernières mises à jour qui ne sont pas forcément toutes présentées dans l'interface de mise à jour du NAS. Mais ce que je veux surtout c'est comprendre. Je te remercie pour ton aide, c'est vraiment sympa d'avoir pris du temps. On va attendre un peu voir si d'autres âmes charitables se manifestent dans cette discussion

Bonjour, Merci, ça fait du bien un peu de chaleur humaine dans cette période d'extrême solitude... Oui, j'ai vérifié et les droits sont les bons pour le compte qui se connecte en SFTP depuis Nextcloud (nc-panel279pr-rw). C'est le même compte qui se connecte avec Filezilla sans rencontrer de problème de suppression de dossier.

Bonjour, Je vous appelle à l'aide car j'ai un problème que je n'arrive pas à résoudre et qui commence à affecter ma santé mentale... Un petit résumé du problème avant de développer : Je crée des espaces SFTP sur un NAS Synology RS3617xs+ (DSM 7.1.1-42962 Update 1) Je monte ces espaces SFTP sur des instances Nextcloud en tant que stockages externes (ce sont des instances Nextcloud qui ne sont pas hébergées sur le NAS mais sur des serveurs distants) Depuis Nextcloud je crée des dossiers sur ces espaces de stockage SFTP. Il est ensuite impossible via Nextcloud de supprimer ces dossiers, il est par contre possible toujours depuis Nextcloud de les renommer ou de les déplacer. Les fichiers peuvent être supprimés sans problèmes, le problème concerne uniquement la suppression des dossiers. Toutes mes instances Nextcloud (une quinzaine en version 25.0.2 et 25.0.3) sont affectées par ce problème. J'ai pensé à un bug Netcloud mais j'ai fais des installations from scratch de versions antérieures (23.0.12 et 24.0.9) et le problème est le même alors que ces versions n'ont jamais été affectées par ce problème. De plus si j'utilise un espace SFTP situé ailleurs que sur le NAS (un serveur Debian de base avec MySecureShell) il n'y a aucun problème pour supprimer les dossiers avec Netxcloud. Ci-dessous vous trouverez toutes les démarches que j'ai effectué pour essayer de comprendre le problème : L'administrateur Nextcloud monte un espace de stockage SFTP "MY-PROJECT" vide et le rend disponible pour l'utilisateur "King". Ce stockage externe est hébergé sur le NAS. L'utilisateur "King" accède au stockage SFTP "MY-PROJECT" depuis son Home Nextcloud. Le dossier est vide comme prévu. L'utilisateur "King" crée un dossier nommé "test-directory" Ci-dessous les logs Nextcloud confirmant la création du dossier "test-directory" (c'est une commande WebDAV) ***REMOVED SENSITIVE VALUE*** - - [21/Jan/2023:17:33:18 +0000] "MKCOL /remote.php/dav/files/king/MY-PROJECT/test-directory HTTP/1.1" 201 626 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:108.0) Gecko/20100101 Firefox/108.0" Les logs du NAS confirment une connexion SFTP depuis Nextcloud et la création du dossier "test-directory" Et effectivement on peut voir le dossier "test-directory" dans FileStation De retour sur Nextcloud l'utilisateur "King" supprime le dossier "test-directory" Il semble que le dossier "test-directory" a bien été supprimé sans aucun message d'erreur. Ci-dessous les logs Nextcloud concernant la suppression du dossier "test-directory". ***REMOVED SENSITIVE VALUE*** - - [21/Jan/2023:17:42:34 +0000] "DELETE /remote.php/dav/files/king/MY-PROJECT/test-directory HTTP/1.1" 204 537 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:108.0) Gecko/20100101 Firefox/108.0" MAIS dans Nextcloud si l'utilisateur "King" clique sur "MY-PROJECT" sur le fil d'Ariane ou qu'il rafraîchit la page, le dossier "test-directory" est de retour ! En fait le dossier "test-directory" est de retour car il n'a pas été supprimé sur le NAS Les logs du NAS montrent la tentative de suppression. Il y a peut-être un indice ici car on voit que Nextcloud essaye de supprimer le FICHIER "test-directory" et pas le DOSSIER "test-directory". Maintenant connectons-nous directement à l'espace SFTP sur le NAS en utilisant Filezilla. Nous utilisons les mêmes identifiants que ceux utilisés pour monter le stockage externe SFTP sur Nextcloud. On supprime le dossier "test-directory" dans le NAS en utilisant Filezilla. Ça a l'air de fonctionner, le dossier "test-directory" n'est plus présent. Et on ne le voit plus non plus dans Nextcloud Allons voir si le dossier a bien été supprimé dans le NAS avec Filestation... Oui, le dossier a bien été supprimé dans le NAS. Regardons à nouveau les logs du NAS La première ligne est la tentative réussie de suppression du dossier "test-directory" en utilisant Filezilla (Event : Delete Folder | Folder). La seconde ligne est la tentative précédente échouée de suppression du dossier "test-directory" en utilisant Netxcloud (Event : Delete | File). Il semble donc qu'en passant par Nextcloud le NAS essaye de supprimer un fichier et pas un dossier. Quelqu'un peut-il me venir en aide pour aller plus loin dans le diagnostic ? Merci pour votre aide. Bonne journée.