Autoris

[netgus]

Bonjour à tous,

Sur mon Syno, je rencontre quelques petits problèmes de configuration, surement liés à mon incompréhension concernant la mise en place des droits.

J'ai besoin de partager mon Syno avec certaines personnes via le net en sftp. La connexion quant à elle est opérationnelle.

J'ai configuré un utilisateur X pour qu'il accède à son dossier HOME ainsi qu'à un autre dossier (pour l'exemple et comme je n'ai pas un imaginaire débordant, je vais l'appeller SHARE). Si je me connecte avec son login, j'accède aux deux dossiers sans problème, je peux copier des fichiers via filezilla, mais je ne pas supprimer (rm /home/topology.net: permission denied). L'utilisateur fait partie du groupe "users".

Le plus amusant, c'est que si je me connecte avec mon compte qui fait partie du groupe administrateur, qui a accès en lecture/écriture sur tous les dossiers, j'obtiens ce type de message: rm /homes/....../topology.net: no such file or directory

N'étant pas un expert dans sous Syno, quelqu'un pourrait-il m'orienter pour que je puisse comprendre où se trouve mon problème.

Merci pour vos différents retours.

[CoolRaoul]

Le fichier qui est dans le home du compte et que tu ne parviens pas a supprimer, il est arrivé la comment?

Quel logiciel clients sftp utilises-tu ?

[netgus]

C'est un fichier que j'ai copié depuis mon Mac (smb://diskstation), mais je rencontre le même problème avec d'autres fichiers

Là, je suis un peu inquiet, car tu es en train de me dire que les droits des fichiers suivent et qu'ils n'héritent pas des droits du dossier où ils ont été copiés.

D'autre part, j'ai essayé plusieurs clients (s)ftp et le problème est le même. (filezilla, FTP On The Go pro pour iPhone)

[CoolRaoul]

(Il y est possible qu'il y ait quelques erreurs dans ce qui suit sur la partie purement Mac car je ne pratique pas cet environnement)

• Pourquoi utiliser SMB sur un Mac alors que le DSM du Syno supporte le protocole de fichier natif MacOs (panneau de conf -> Win/Mac/NFS ->"service de fichier mac")?
  
• Comment as-tu accédé au répertoire home du compte de l'utilisateur "X" a partir du Mac alors que ta connexion mac -> syno avait été établie en s'authentifiant (j'imagine) sous un autre compte que "X"?
  

Bon, dans *tous* les cas, il faut comprendre que la fonction du dossier "home" est de contenir des fichiers *privés* de l'utilisateur. Il n'est pas fait pour contenir des données à partager entres comptes différents.

Dans ce contexte, creer/copier des fichiers dans le HOME d'un compte "A" en état connecté sous un compte "B" n'est pas naturel. (Je n'ai pas pu reproduire le comportement que tu décrit cependant: ayant créé un nouveau compte "frais" pour mes tests, un fichier copié dans son home en étant connecté en admin peut bien être supprimé par l'utilisateur lui-même)

Cela dit, pour faire des échanges la bonne approche est de créer un répertoire partagé (et d'ailleurs c'est ce que tu as commencé a faire avec le dossier dit "SHARE", alors pourquoi passer par "home"?) ainsi qu'un groupe (panneau de conf -> groupes)

Les différents utilisateurs impliqués dans les échanges seront rendus membre du groupe.

On configure les droits d’accès globaux de ce répertoire en fonction des utilisateurs (ou des groupes de ces derniers, c'est mieux).

Si tu le souhaites, il est possible de régler plus finement les droits au niveau dossier et fichier via FileStation (menu contextuel "propriétés") pour restreindre plus avant.

Et là normalement plus de problèmes.

Modifié le 25 novembre 2012 par CoolRaoul

[netgus]

Tout d'abord merci, car je suis impressionné par cette communauté (vous). À chaque fois que j'ai eu un problème, j'ai eu bien plus que des réponses...

La petite histoire:

Initialement, j'ai utilisé mon Syno à titre personnel et puis, avec mes ami(e)s et certaines personnes, j'ai commencé à partager mon espace pour des échanges. Le problème, c'est l'isolation des données qui sont déposées sur mon Syno. Aujourd'hui, je dois bien avoir plus d'une dizaine de personnes qui accèdent au Syno en (s)ftp. Il faut gérer les droits, la bande passante.

J'ai donc créé des comptes avec le dossier home, puis j'ai donné l'accès au dossier home et pour d'autres, certains accès à d'autres dossiers, mais l'objectif est d'échanger. Moi, j'y accède avec mon compte admin du Syno. En plus clair, je copie ou déplace les fichiers au besoin.

Pourquoi j’utilise CIFS, bien c’est qu'initialement, mon environnement de travail était essentiellement sous Windows et puis le temps a passé et les envies aussi. Moi sous Mac, ma femme sous Windows, etc...

Je vais tout modifier en suivant tes conseilles et je reviendrai faire un petit retour.

Merci encore à toi

[netgus]

En suivant tes conseils, je viens d'ouvrir "file station" pour voir un peu comment cela fonctionne et je suis surpris de voir que quand tu es sur le dossier FTP, créé par le système lui-même, je peux voir un onglet "permission" et un autre "privilège avancé", alors que l'ensemble des autres dossiers créé par syno et moi-même, je ne retrouve pas cet onglet, mais un autre "configuration des privilèges".

Si je prends un utilisateur quelconque qui fait partie du groupe local users (RW) et que j'essaye de supprimer un fichier, il a un accès refusé.

Si je prends le même utilisateur qui fait partie du groupe local admistrators (RW) et que j'essaye de supprimer un fichier, il a un No such file.

Comme le dossier FTP permet plus de granularité, j'ai autorisé mon utilisateur a y accéder, ce qui n'était pas le cas initialement. J'ai copié un fichier quelconque depuis mon Mac dans le dossier racine du FTP. Je vois bien que le owner, c'est moi. Je propage les droits everyones et je fais le test de suppression. Accès refusé. Je change le owner et je mets le groupes users. Même situation. Je définis mon compte utilisateur comme owner du fichier. Même combat. Bon, la colère me prend, je sors le fusil et là plus de problèmes. Merci les gars, RDV au prochain Syno.

Plus sérieusement, j'ai aussi repassé mon utilisateur dans le groupe admin et le résultat est "No such file"

L'accès depuis le Mac se fait comme cela: smb://diskstation avec mon compte admin de mon Syno.

Mon problème doit être ailleurs, mais où?

Quel type de tests pourrais-je faire pour indentifier mon problème et éventuellement le solutionner, ce qui serait pas mal.

J'ai eu l'idée de me connecter à file station avec le compte de l'utilisateur pour voir si j'avais le même comportement et bien non. Je suis en mesure de supprimer n'importe lequel des fichiers même si le owner est mon compte et que le fichier vient d'une copie depuis mon Mac.

J'ai fait alors un test avec un autre client (s)FTP (Cyberduck) est l'erreur remonté: est Permission denied (SSH_FX_PERMISSION_DENIED: The user does not have sufficient permissions to perform the operation.)

Modifié le 26 novembre 2012 par netgus

[CoolRaoul]

En suivant tes conseils, je viens d'ouvrir "file station" pour voir un peu comment cela fonctionne et je suis surpris de voir que quand tu es sur le dossier FTP, créé par le système lui-même, je peux voir un onglet "permission" et un autre "privilège avancé", alors que l'ensemble des autres dossiers créé par syno et moi-même, je ne retrouve pas cet onglet, mais un autre "configuration des privilèges".

Pour que l'onglet "privilege avancé" soit présent il faut avoir activé la prise en compte des ACL sur le dossier partagé, comme ceci:

Par contre il ne me semble pas que le système créé de dossier "FTP" (en tous cas ce n'est pas le cas sur mon NAS)

[CoolRaoul]

Si je prends un utilisateur quelconque qui fait partie du groupe local users (RW) et que j'essaye de supprimer un fichier, il a un accès refusé.

Si je prends le même utilisateur qui fait partie du groupe local admistrators (RW) et que j'essaye de supprimer un fichier, il a un No such file.

Comme le dossier FTP permet plus de granularité, j'ai autorisé mon utilisateur a y accéder, ce qui n'était pas le cas initialement. J'ai copié un fichier quelconque depuis mon Mac dans le dossier racine du FTP. Je vois bien que le owner, c'est moi. Je propage les droits everyones et je fais le test de suppression. Accès refusé. Je change le owner et je mets le groupes users. Même situation. Je définis mon compte utilisateur comme owner du fichier. Même combat. Bon, la colère me prend, je sors le fusil et là plus de problèmes. Merci les gars, RDV au prochain Syno.

Plus sérieusement, j'ai aussi repassé mon utilisateur dans le groupe admin et le résultat est "No such file"

L'accès depuis le Mac se fait comme cela: smb://diskstation avec mon compte admin de mon Syno.

Mon problème doit être ailleurs, mais où?

Quel type de tests pourrais-je faire pour indentifier mon problème et éventuellement le solutionner, ce qui serait pas mal.

Tout ça n'est pas facile a suivre je dois dire...

Même avec énormément de bonne volonté je ne parviens pas à reproduire les étapes.

Tu commences par nous parler d'un utilisateur quelconque faisant partie d'un groupe et ensuite du *même* utilisateur mais avec des groupes différents: c'est le même ou pas alors?

Il y a aussi des phrases que je ne comprend pas aussi ("Je propage les droits everyones") : propager les droits d'un dossier aux objets qu'il contient je vois bien, mais dans le cas d'un *fichier* je ne vois pas en quoi cela peut consister.

Franchement désolé, peut-être que je suis un peu fatigué aussi.

[netgus]

Non, c'est surement moi qui la tête dans le guidon...

L'utilisateur, c'est le même.... Louis pour faire simple et en plus, c'est bien le nom du compte...

Louis fait partie du groupe utilisateur local avec les droits par défaut RW sur FTP, Home, etc...

Actuellement, il est en mesure de lire et d'écrire, mais il ne peut pas supprimer (access denied) et si je lui donne le droit dans le groupe administrateur local, on obtient le message suivant (No such directory) et ça, peu importe le dossier.

Si je me connecte avec le compte de louis pour utiliser file station, le problème ne se pose pas, il est en mesure de supprimer n'importe lequel des fichiers qu'il a copiés ou que j'ai copiés depuis mon Mac, mais là, on ne fait de SFTP.

Quand je parlais de propagation des droits, je parlais du dossier racine du serveur FTP où par défaut le compte everyone est configuré. J'ai simplement cliqué sur le fichier et demandé que les droits déclarés du dossier viennent écraser les droits du fichier (inclure les permissions héritées, un truc comme ça) et j'aie aussi fait le contraire en cliquant sur le dossier racine et demandé la propagation des droits.

Je ne me rappelle pas non plus avoir créé le dossier FTP, mais je l'ai peut-être fait.

Le cout du "windows acl", je pensais que c'était pour l'ensemble des dossiers. Je serai encore bête ce soir. Merci

Je vais faire un test en FTP simplement pour voir si le problème est global ou lié au SFTP

[CoolRaoul]

Si je me connecte avec le compte de louis pour utiliser file station, le problème ne se pose pas, il est en mesure de supprimer n'importe lequel des fichiers qu'il a copiés ou que j'ai copiés depuis mon Mac, mais là, on ne fait de SFTP.

Si je comprend bien, il semblerait que ce soit l'aces sftp le coupable.

A confirmer par tes tests en ftp.

[netgus]

Oui, je viens de faire le test avec une connexion en ftp et je n'ai pas de problème pour supprimer ce fichier.

J'ai refait un test vite fait en SFTP depuis la même application et je retrouve mon problème.

Maintenant, est-ce que je suis le seul à avoir ce problème ?

Et comment remonter le problème ?

[CoolRaoul]

Et comment remonter le problème ?

https://myds.synology.com/support/support_form.php?lang=fre

[netgus]

Message posté. En attente de retour.

Merci