Problème accès partage Samba

[Mikeul]

Bonjour à tous

Depuis quelques temps, je n'arrive plus à accéder à l'un de mes partages samba (les autres fonctionnant sans souci). Je n'ai pas touché à la configuration de ce partage sur mon Syno depuis très très longtemps, donc je suspecte une mise à jour quelconque (PC client ou Syno ?).

Depuis un poste Win 10, j'obtiens le message d'erreur suivant :

Pour être précis, il s'agit d'un partage d'archives/sauvegarde avec une configuration spécifique, auquel un seul compte dédié a accès (pour éviter les problèmes). Il est masqué dans le navigation réseau mais accessible habituellement via \\monNAS\dossier (soit avec l'IP, soit avec le nom Netbios). Évidemment, comme j'utilise un compte dédié, lorsque je m'y connecte depuis ma session win10 personnelle, je dois donc rentrer le login et le mot de passe.

Au niveau des options smb, je me suis aperç que j'avais smb 1 mininum lorsque ce problème s'est présenté. J'ai modifié avec smb2, sans que cela ne change quoi que ce soit.

Au niveau des logs :

• Dans l'observateur d'événements de Win 10, j'ai le message suivant : Le client SMB n’a pas pu se connecter au partage. Erreur : {Accès refusé}. Un processus a demandé l’accès a un objet, mais il ne bénéficie pas des autorisations nécessaires. Sans plus de détails
• Dans le centre des journaux du Syno, aucune trace d'erreur de connexion

Au niveau des permissions locales sur le Syno, c'était le compte root qui avait accès au dossier lui-même (aucun droit pour les groupes ni les autres utilisateurs), puis le compte dédié sur tous les sous-répertoires à l'intérieur. J'ai modifié pour mettre le compte dédié dès la racine du partage à la place de root, ça n'a rien modifié.

Côté NAS, je suis sur un Syno DS218+, DSM 6.2.3-25426.

Je sèche, une idée ? 🙂

 

[.Shad.]

Salut,

Tu peux faire un test, fais en sorte que le groupe "users" ait accès à ce répertoire, et tente de te connecter à nouveau.

Modifié le 28 juin 2020 par .Shad.

[Mikeul]

Hello

ça fonctionne...

Du coup, je me dis que je vais créer un groupe spécifique pour mon utilisateur dédié, en donnant les droits à ce groupe sur le partage (et en supprimant les droits du groupe users). Même résultat que précédemment, le problème est toujours là. Du coup, tu as une piste en tête ?

Modifié le 29 juin 2020 par Mikeul

[.Shad.]

C'est ce que je t'aurais aussi proposé, toutefois tu peux essayer de faire une redondance de droits entre le groupe et l'utilisateur, je sais que via Docker par exemple, il faut parfois que mon groupe ET mon utilisateur aient les droits sur les volumes montés, sinon j'ai des erreurs d'accès non autorisé. Peut-être que ça marchera.

[Mikeul]

Tu parles de droits Synology dans le paramétrage des partages ou directement sur le filesystem ?

Ce qui est curieux dans mon cas, c'est que je n'ai fait, manuellement, aucune modification de configuration depuis des lustres . Je ne m'explique donc pas pourquoi subitement, cela ne fonctionne plus. Il y a évidemment un truc qui a bougé mais je n'ai pas (encore) trouvé lequel.

[.Shad.]

Pas en SSH, dans DSM directement oui.
Donc octroyer les droits par le groupe et l'utilisateur.

[Mikeul]

J'ai refait le test, en créant un groupe dédié, en lui donnant les droits sur le partage et en mettant ce compte dédié dans ce groupe : même résultat et même message d'erreur.

Il n'y a qu'en donnant les droits sur le group users que ça fonctionne. Sauf que ce n'est pas ce que je veux. Je pourrais modifier les droits individuels de chaque compte mais ce n'est pas un bon comportement ; ça veut dire que je devrai le faire pour tout nouveau compte (alors que je veux le comportement par défaut inverse).

 

[.Shad.]

Et tu as tout à fait raison, ce groupe users obligatoire est pour moi une infâmie...

Le 27/06/2020 à 11:53, Mikeul a dit :

Au niveau des permissions locales sur le Syno, c'était le compte root qui avait accès au dossier lui-même (aucun droit pour les groupes ni les autres utilisateurs), puis le compte dédié sur tous les sous-répertoires à l'intérieur. J'ai modifié pour mettre le compte dédié dès la racine du partage à la place de root, ça n'a rien modifié.

Je viens de voir ce passage, si tu as joué avec du chmod via SSH, il se peut que tu aies supprimé la surcouche d'ACL de DSM (quand tu fais un ls -l dans un dossier, la surcouche est présente si tu as un "+" à la fin des permissions UNIX => drwxrwxrwx+). J'ai peur que cela puisse être lié à ton problème, pour corriger ça il suffit de ré-appliquer les permissions depuis DSM normalement.

Autre chose que tu peux tester, tenter de faire un montage CIFS du même dossier depuis Linux, et voir si tu aboutis à une erreur également.

[Mikeul]

Le + y est toujours. J'en ai d'ailleurs profité pour rajouter les droits sur le dossier au nouveau groupe dédié que je viens de créer, mais rien à faire, toujours le même problème.

Je crois me souvenir que j'avais eu un souci similaire il y a plusieurs mois et j'avais finalement supprimé et recréé le partage. Si je ne trouve pas, je vais finir par faire ça.