[Résolu] Impossible de supprimer des dossiers via SFTP (stockage externe Nextcloud)

[zigobs]

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.

Modifié le 25 janvier 2023 par zigobs
Résolu

[MilesTEG1]

@zigobsBonjour,

Plein de détails sur le souci et ce que tu as tenté, c'est top 👍🏻

J'ai essayé de monter un dossier SFTP, et de refaire ce que tu as fait : créer un dossier, puis le supprimer depuis Nextcloud.

Et bien chez moi, il est bien supprimé du NAS distant, pas de soucis.

J'ai regardé après sa création les droits dessus, et il s'agissait bien des droits de l'utilisateur utilisé pour connecter le dossier SFTP.

Je pense que tu dois avoir un souci de permission quelque part ^^

Ton utilisateur SFTP a-t-il bien tous les droits sur le dossier monté ?

[zigobs]

Bonjour,

il y a 36 minutes, MilesTEG1 a dit :

Plein de détails sur le souci et ce que tu as tenté, c'est top

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.

 

Modifié le 24 janvier 2023 par zigobs
Image

[MilesTEG1]

Hmmm, là je sèche...

Il est installé comment ton NextCloud ?

Le pare-feu du NAS est-il bien configuré ?

Honnêtement, je ne vois pas ce qui pose soucis...

Y-a-t-il des caractères spéciaux dans les chemins d'accès ?

[zigobs]

il y a 6 minutes, MilesTEG1 a dit :

Hmmm, là je sèche...

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

[MilesTEG1]

il y a 9 minutes, zigobs a dit :

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.

Ha oui, ce serait une bonne chose de faire les MAJ en premier lieu, et de tenter le redémarrage du nas.
Et ensuite, si ça n'a pas réglé le souci, essaye de créer un nouvel utilisateur ayant les droits sur le dossier et les droits SFTP, et retente une connexion SFTP avec ce nouvel utilisateur.

edit : vérifie aussi que dans les paramètres avancés du SFTP, tu aies ça comme ceci :

[zigobs]

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.

[MilesTEG1]

il y a 30 minutes, zigobs a dit :

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.

C'est bon à savoir, merci pour le retour.
Faut que je vérifie si de mon côté, sur le partage utilisé lors de mon essai la corbeille était activée ou pas ...

Vérification faite, la corbeille est bien désactivée 🙂 

[zigobs]

Bonjour,

Et pour clore définitivement l'affaire voilà un complément de réponse de Synology :
 

Citation

This behavior is related to a known issue that will be fixed in DSM 7.2.

In the meantime, there is a patch to apply so that you can continue to use the recycle bin on these folders accessed via SFTP from Nextcloud.

Il s'agit donc bien d'un bug qui sera corrigé dans la version DSM 7.2...

Bonne journée.

[MilesTEG1]

Ok ! En soi, c'est une bonne nouvelle.
Je serais toi, je creuserais quant-à la date de sortie de DSM 7.2 😄 

Et le patch dont il parle, c'est quoi ?

[zigobs]

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.