Fenrir

Généralement les droits les plus restrictifs l'emportent (interdire+autoriser=interdire). De manière général on évite de mettre des droits "négatifs" (refuser/interdire), on se contente de ne pas donner de droits par défaut, puis on ajoute des autorisations. Pour l'autre question : de base sur les partages Windows, Synology applique des autorisations NTFS les permissions des comptes/groupes locaux (ceux de ton windows) sont donc interprétées sous W7 et 8 ton compte était probablement dans un groupe autorisé (administrators par exemple) sous W10, ce n'est peut être pas le cas, ou alors il traduit les droits différemment

Je ne joue jamais avec les dossiers/fichiers système par défaut des mes syno. Tu peux créer une conf custo dans /etc/php/fpm.d/ (include=/etc/php/fpm.d/*.conf), elle sera persistante. Normalement les paramètres écraseront ceux de la conf par défaut

Tu peux monter un dossier de ton nas DANS un dossier du conteneur, il faut juste faire attention à ce qu'on fait

En théorie, si les disques ne sont pas HS, oui. Il suffit de les brancher sur un pc (sous linux le pc) et de monter les disques (selon le type de raid, c'est plus ou moins simple). C'était quel type de raid (tu indique raid10 dans ta signature et shr dans ton post) ? Pour rappel, on peut par exemple faire du raid1 ou du raid1 shr, du raid 5 ou tu raid 5 shr, ...

Sur les modèles supportés, vous pouvez utiliser docker pour installer un centreon engine, ça fonctionne très bien et ce n'est pas trop lourd (bcp moins qu'un nagios). Vous pouvez aussi essayer cacti (c'est du php, donc il devrait s'installer sans soucis, par contre il faudra peut être compiler net-snmp pour le syno). Sinon vous trouverez de nombreux outils plus petit sur github et soureforge, mais la plupart sont des binaires, donc pas certain qu'ils fonctionnent sur un syno

nop, ne les monte pas, branche les simplement et utilise les outils du constructeur pour tester le disque (en commençant par les valeurs smart) Mais effectivement, que les 4 tombent en rade en même temps est suspect et peu probable, mais il est possible qu'ils n'aient pas apprécié ton reset Ton raid 10, tu l'as monté comment ? 2 raid1 agrégés en un raid 0 2 raid0 agrégés en un raid 1 (ce qui n'est pas un raid 10 mais un raid 01) Dans tous les cas, je pense que tu vas devoir ressortir les backups. Mais en formatant les disques (s'ils n'ont pas d'erreur), tu devrais éviter la case : je rachète 4 disques En passant, évite les raid combinés, même si en théorie ils sont plus rapide, en pratique le gain est marginal sur ce type de matériel (un raid5 de 3 disques + un disque de spare offre des perf similaire et le même niveau de protection)

Donc elle ne fait pas de FTP ? L'adresse commence par quoi (choisi un numéro) : http:// https:// ftp:// ftps:// sftp:// cifs:// nfs:// afp://

vérifie l'état de tes disques, si possible test avec un autre disque

Essaye sans aucun disque, il arrive parfois qu'un disque en panne empêche les syno de booter

Afficher la liste des containers : docker ps -a Supprimer un container : docker rm ID du container Supprimer un container lancé : docker rm -f ID du container Afficher la liste des images : docker images Supprimer une image : docker rmi ID de l'image Pour accéder au contenu d'un container, il y a plusieurs méthodes : le plus simple, mais c'est déconseillé sauf en dev : tu peux lancer le container en lui attachant un shell : https://docs.docker.com/articles/basics/ le plus propre : tu montes les dossiers dont tu as besoin (ce n'est pas toujours possible, ça dépend de comment a été créé l'image) le plus courant mais pas recommandé : tu ajoutes une application dans le container qui te permet de le gérer (ssh, webmin, ...), idéalement en créant un Dockerfile si c'est juste pour exécuter des commandes, docker exec est suffisant Après il y a plein d'autres manières et d'outils de gestion, mais dans tous les cas, il ne faut pas modifier le filesystem d'un container depuis l'hôte. Commence par faire un : docker inspect okvic77/airtime Ça devrait t'afficher les infos de l'images (on voit d'ailleurs qu'il y a 2 ports en écoute, il faut donc modifier la commande de lancement) Ensuite recréé un container avec un sheel, regarde comment est installée l'appli Je ne vais pas rentrer plus dans les détails, trop long, mais tu as tout dans les docs officielles de docker

essaye de créer un nouveau partage, sans droits particuliers (droits par défaut) et refais les tests

Je ne sais pas exactement ce que fait ton "site", mais le passer dans un container ne devrait pas être si compliqué (surtout que tu devrais pouvoir le faire en parallèle de l'existant sans conflit). Pour la parallélisation des taches, je ne vois pas ce que tu peux faire en php via des call http que tu ne puisse faire avec des scripts (qui peuvent être en php) et cron. On verra déjà ce que ça donne avec les réglages de php-fpm

Pour le SHR, c'est simplement du LVM standard au dessus d'un raid standard, rien de spécifique synology et en aucun cas ça ne peut jouer sur la compatibilité d'un transfert de fichier via le réseau. Par contre un disque incompatible ou défectueux ce n'est pas rare et un formatage de bas niveau ne révèle pas toujours les erreurs, surtout en multi plateaux. Vérifie les status smart et le taux de relocalisation des blocs (l'erreur 38 est généralement liée à un disque HS) Pour ta copie de fichiers, si tu atteins les limites de rsync (de mémoire il bloque avec ds chemins de 1K, ce qui commence à faire très long) , tu peux piper le transfert avec un tar : tar cpf - /volume1/source | ssh login@destination "tar xpf - -C /volume1/cible" Mais en générale les problèmes de longueur de chemin ou de nom de fichiers interviennent quand il y a un windows (ou un cygwin) dans la boucle (limite à 256 caractères)

Si tu utilises docker, je te recommande de migrer ton appli dans un conteneur : ça évitera de devoir tuner le syno tu seras plus libre d'ajouter des dépendances/logiciels tiers, comme nginx relancer le conteneur (quelques secondes) sera bien plus rapide que de relancer le syno en cas de changement de syno, tu n’auras qu'à exporter/importer ton conteneur et ça sera plus sécurisé (faire des appels système en php via le serveur web, c'est mal) Sinon je te suggère de repenser ton système, plutôt que d'appeler tes scripts via php-apache-php, enregistre les "taches" dans un fichier ou une base et créé un script lancé en crontab qui traite ces taches.

Tu as essayé de reconfigurer ton pool fpm ? Par défaut fpm est configuré en mode dynamic, ce qui est loin d'être le plus efficace : pm = dynamic pm.max_children = 20 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3 Essaye avec ces paramètres (à la place des précédents) : pm = ondemand pm.max_children = 5 pm.process_idle_timeout = 10s pm.max_requests = 200 Pour la seconde erreur, ça vient d'apache, mais c'est probablement lié à la première erreur (fpm ne répond pas=>les requêtes en attente s'accumulent dans apache), ou alors tu as beaucoup de visiteurs, dans ce cas il faut faire du tuning (optimisation des sites, reverse px, cache, ...)

FTP via le navigateur Tu parles de navigateur WEB (firefox, IE, ...) ou de client FTP (filezilla, ftprush, ...) ?

Je viens de tester, l'image contient déjà un serveur postgresql, tu as juste créer le conteneur : docker run --name test-airtime -p 8001:80 -d okvic77/airtime Pas besoin de l'image de postgres. Sinon pour ta culture, pour linker 2 conteneurs, il faut que le premier existe docker run --name test-postgres -e POSTGRES_PASSWORD=password -d postgres docker run --name test-appli --link test-postgres:alias-postgres -p 1234:5678 -d image-appli La première commande par créer un conteneur nommé test-postgres à partir de l'image postgres, la seconde commande va créer un conteneur test-appli à partir de l'image image-appli et lier ce conteneur au conteneur test-postgres.

Ça dépend : si le nas est accédé en simple serveur de fichier (smb par exemple) : le nas ne fait que fournir le fichier brute, donc peu de cpu si le nas est accédé via dlna : en fonction de ce qui est négocié avec le périphérique, le nas peut transcoder le fichier ou l'envoyer en direct si le nas est accédé via DSVideo (sur ipad par exemple) : en fonction des capacités de lecture du périphérique, le nas peut transcoder le fichier ou l'envoyer en direct

De manière générale, si vous souhaitez que vos nas ne bossent pas quand vous regardez une vidéo sur un iPad ou équivalent, convertissez les en m4v. Si vos vidéos sont dans un format qui, d'après le syno, nécessite une conversion, votre nas va convertir la vidéos "à la volée" => la qualité de la vidéo et/ou du son va être moins bonne le cpu du nas va s'emballer (d'où l’intérêt des modèles play) ce qui va aussi limiter le débit du nas Il y a plein de post sur ce sujet, faites le test avec quelques vidéos converties en m4v : h264+aac

Ton IP publique a peut être changé ou alors tu as touché aux réglages qui fonctionnaient

Ce n'est pas le choix d'une ip spécifique (ça aurait probablement fonctionné en prenant la centième suivante), mais d'une IP dans le même réseau. Si tu es plus à l'aise en math, dit toi qu'une adresse de réseau n'est que la multiplication binaire d'une IP par un masque

C'est simplement que PHP n'a pas le droit d'accéder à ton dossier Je te recommande plutôt d'utiliser les fonctions de partage de VideoStation, PhotoStation et FileStation

ça ressemble à un problème avec php (mémoire, disque ou erreur de code) => vérifie tes logs

PhotoStation a sa propre gestion de droits qui vient en plus de celle du syno, connecte toi en admin et vérifie que tes autres utilisateurs ont les bons privilèges

Les red pro ont plus de cache et sont des 7200rpm, c'est pour ça qu'ils sont plus rapide, mais pour un usage domestique, je trouve que c'est un peu du luxe Pour les onduleurs, tu as une liste sur le site de syno : https://www.synology.com/fr-fr/compatibility?search_by=category&category=upses&p=1