.Shad.

C'est plus compliqué que ça. Le "service" Docker est par défaut exécuté par root, par opposition à Docker Rootless qui existe depuis plusieurs mois maintenant (mais non présent sur Synology). C'est Docker Rootless qui permet d'exécuter le service Docker avec des utilisateurs non privilégiés. Mais a de fait certaines limitations, voir ici : https://docs.docker.com/engine/security/rootless/ Quand tu spécifies user:group, tu dis que le service à l'intérieur du conteneur est exécuté par l'utilisateur/groupe spécifié. En aucun cas c'est cet utilisateur qui exécute le conteneur sur le NAS, tu peux le vérifier en tapant : ps aux | grep docker Tu verras que root est l'utilisateur exécutant. Donc pour te répondre : Du tout, tu dis à ton conteneur que l'application Bitwarden doit être exécutée par un utilisateur 1001:1001 au sein du conteneur. Si l'image est prévue pour être exécutée par root, alors ça marchera uniquement si tes exécutables sont par exemple en 777, ce qui est peu probable. Si 1001:1001 peut écrire dans un dossier dans un conteneur, alors ces fichiers appartiendront à 1001:1001, et sur le NAS tu verras 1001:1001, sauf si un utilisateur/groupe d'UID/GID 1001 existe, auquel cas tu verras les noms d'utilisateur et de groupe associés (ce qui n'est pas mon cas sur mon DS918+). C'est là que les PUID et PGID entrent en jeu et nous rendent de fiers services sur un NAS, où le classique 1000:1000 n'est pas exploitable comme sur la grande majorité des distributions Linux. Ils permettent de dire que par exemple l'utilisateur toto d'UID 1045 sur le NAS, et le groups users de GID 100 sur le NAS, sont mappés vers 1001 et 1001 du conteneur. C'est là que la magie opère, car du coup tu n'as pas à gérer cet UID dans DSM, il suffit gérer correctement les accès pour le combo 1045:100. J'espère que c'est plus clair, si pas n'hésite pas à demander, c'est un concept parfois difficile à appréhender pour les débutants et même les utilisateurs réguliers, ça pourrait donc servir à d'autres.

@molinadiaz Oui c'est effectivement plus lourd, moi j'ai réglé le problème en déportant mes services sur une Debian, seules les données "dures" sont sur le NAS, et tout est monté par Samba.

DSM est régi par des ACL, les seules façons de t'assurer que des sous-dossiers d'un dossier partagé ne puissent être parcourus indifféremment sont : - ce que tu as fait, càd mettre des règles des refus, elles sont prioritaires dans la résolution des permissions MAIS c'est fastidieux à gérer. - chmod le dossier partagé docker, ça enlève la couche d'ACL, MAIS je ne pense pas que ce soit une bonne solution, car ça contrevient à la philosophie de DSM. Si tu veux vraiment compartimenter, alors je te conseillerais de créer une VM minimale dans laquelle tu installes Docker et là ce sont des permissions UNIX, tu as les mains libres. Ca aurait l'avantage aussi de limiter les failles potentielles lié à l'utilisateur root, pour discuter de l'autre sujet que tu as ouvert concernant les utilisateurs exécutant les conteneurs. A toi de monter un maximum de volumes en lecture seule quand la finalité le permet. Et ça ne change rien pour Portainer. Souvent les écritures se font dans un dossier config ou data, les données elles-mêmes (musique, videos, documents, etc...) peuvent l'être en lecture seule.

Est-ce que tu as appliqué la propriété des dossiers via File Station ou via chmod en SSH ?

Hello, Il y a une petite confusion entre plusieurs éléments : - PUID et PGID ne définissent pas QUI exécute le conteneur, ils définissent le mappage à faire entre un utilisateur dans le conteneur (abc chez Linuxserver souvent) et un utilisateur sur l'hôte. Ces variables ne sont là que pour s'affranchir des problèmes des permissions et du fait que sur les NAS, les UID < 1024 sont réservées par le système. - UID et GID sont les ID numériques des utilisateurs - "user:group" (group étant facultatif) que tu définis dans le fichier compose disent QUI exécute le conteneur. Pour que ça fonctionne, il faut que le Dockerfile de l'image le prévoit. La plupart des images sont prévues pour être exécutées via root, sauf à ce que le développeur prenne la peine de créer un utilisateur non privilégié. C'est la bonne pratique mais malheureusement trop peu répandue. Si par laxisme ou par volonté, un utilisateur lambda du conteneur pourrait faire fonctionner l'application, alors tant mieux, mais la plupart du temps tu auras des problèmes de permission comme dans ce cas-là.

Bienvenue!

J'espère que tes données sont sauvegardées, ton NAS a déjà un petit âge et fait partie de la série maudite. Probable que ça ne dure pas indéfiniment.

Bienvenue parmi nous

Ton script ressemble à quoi ?

Quelle version de DSM ? Quel système de fichier ?

La bonne pratique c'est que chaque réseau macvlan sur chaque périphérique ait une plage d'IP unique et non partagée. Rien n'empêche de faire ce que tu as fait, tant que tu vérifies que l'IP attribuée à un conteneur est unique sur ton réseau. En définissant des plages différentes tu préviens la duplication d'IP. Autre question, je vois que tu mets 192.168.1.167 dans REV_SERVER_TARGET, cette IP correspond à quoi ? Je m'attends à voir l'IP de la passerelle OU l'IP d'un des deux NAS, vu que de souvenir tes deux NAS hébergent une zone locale (maître et esclave) OU rien du tout si Pi-Hole devient ton serveur DNS local. De prime abord je dirais que 192.168.1.167 c'est l'IP d'un conteneur en macvlan, mais lequel... ? Relire peut-être le point 5-C-2.

Welcome !

Salut et bienvenue, crée un fil à part pour ton problème.

Je te conseille d'utiliser le DockerMod Install-Package de Linuxserver, il permet d'ajouter les paquets que l'on souhaite à ton conteneur, de façon persistante et reproductible : https://github.com/linuxserver/docker-mods/tree/universal-package-install Et ça s'intègre facilement dans le docker-compose d'une application (ici Domoticz). Essaie d'identifier les bibliothèques et binaires appelés dans ton script.py et installe ce qu'il faut pour que ça tourne.

Peux-tu adapter le format de ta requête au template demandé ici ?

C'est moi ou c'est dans Komga cette erreur ? Je ne connais pas l'application désolé, je suis tombé sur ça, j'imagine que toi aussi : https://www.authelia.com/integration/openid-connect/komga/ En dernier recours, tu peux toujours aller sur le Discord d'Authelia, les gars sont très dispos, ils m'ont bien dépanné à l'époque.

Ca dépend à combien il le touche, j'ai eu le mien à 40€ (état neuf pour ainsi dire). @tipiake Idéalement je vais dans le sens de @MilesTEG1, les modèles "+" vieillissent beaucoup mieux.

Mon Pi-hole sur le NAS fonctionne bien avec les variables d'UID et GID. Pour celui sur Debian le problème se pose moins car on est moins embêté avec les permissions. Cool si ça fonctionne bien en l'état alors, tu as utilisé les variables d'UID et GID comme précisé dans ce message ?

Pour l'erreur 1, est-ce que tu as testé de mettre le hmac_secret dans un fichier aux droits d'accès limités comme pour les autres clés ? - AUTHELIA_IDENTITY_PROVIDERS_OIDC_HMAC_SECRET_FILE=/config/secrets/oidc Pour les secrets c'est ici : https://www.authelia.com/configuration/methods/secrets/ Et du coup ne rien mettre en regard de hmac_secret dans le fichier de configuration ? le message laisse supposer que tu l'as défini aux deux endroits. Erreur 2, a priori le hmac_secret est bien importé, mais comment savoir dans quel ordre les données sont traitées, l'erreur 1 aurait peut-être pu surgir juste après.

Bienvenue !

Alors il te faut un NAS inclus dans cette liste : https://kb.synology.com/en-ro/DSM/tutorial/Which_Synology_NAS_models_support_the_facial_recognition_feature_on_Synology_Photos Si ça peut t'aiguiller dans ton choix.

Welcome back alors !

Pour que ça bascule automatiquement en https il faut avoir une redirection http -> https, tu peux la mettre en place en suivant le point VII du tutoriel sur le proxy inversé : Concernant : Tu devrais regarder pour mettre en place un serveur DNS local, car là pour accéder à ton NAS tu passes par Internet, un peu dommage de faire Paris - Tours en passant par Strasbourg. Voir le tutoriel suivant :

Est-ce que tu fais ton test en local ou depuis la 4G ? Que donne localement dans une invite de commande (PC ou Mac ou terminal Synology) : nslookup virtuel.toto.synology.me Ca doit pointer vers 192.168.1.20

Si c'est juste pour stocker, et si tu ne comptes pas utiliser les fonctions avancées de Synology Photos, alors un modèle J sera suffisant. En revanche, j'éviterais d'acheter maintenant un modèle de la série 16 et -, le support DSM touchera bientôt à son terme.