Einsteinium

Hum classique j'ai deja eu la blague =) un petit script, fixmultimedia.sh : #!/bin/sh cd /var/spool rm syno_indexing_queue* killall synoindexd killall synoindexscand exit 0 Après tu exécute via le gestionnaire de tache ou alors tu tape les ligne en ssh hormis la première et la dernière, après tu relance une indexation via le gestionnnaire ;-)

Ba non je trouve sa logique, sachant que les comptes sont lier entre tous les services et certain paquet d'application que l'on ne peut pas désactivé, exemple concret juste plus haut avec les mails... Je trouve sa dommage que des paquets quand même officiel ne permette pas cette désactivation, comme pour l'accès à l'interface web ou même un filtrage par IP des comptes.

Tiens c'est marrant finalement... Surtout que le mail de test était ok, les joies de l'informatique =D @domlas euh... Hors contexte, mais alors totalement... Sa me fait même sourire de lire et voir tout ça surtout quand on voit qu'une semaine avant il y avait 6 sdf morts de froid qui ont eux le droit à une petite brève et exit le crash d'avion avec 162 morts dont un français ou encore la tuerie de 2000 personnes en Afrique des derniers jours... Bref on va pas en faire un débat, mais stop par pitié... J'en peux plus !

En gros il dit juste que chaque utilisateur en se connectant au dsm puis ds file ne voit que certains dossiers, il a pas compris ton cas ou tu veux carrément bloquer l'accès au dsm, moi personnellement je te comprends, j'avais crée un compte uniquement pour la sauvegarde Time machine et Pc fixe, j'étais pas fan que cette utilisateur soit accessible quand j'ouvrais encore l'interface dsm sur le web.

cela servira peu être à d'autre au passage, je le rajouterais en première page.

La tout à fait d'accord, au pire ouvre un sujet en mettant directement le lien de ticket et le message type, en si mettant à plusieurs... Sa motivera

Des que j'ai du temps libre, j'irais faire un tour ssh pour récupérer et modifier le script de connection ;-)

Oui mais synology n'a pas prévus cette option, tu peux voir à modifier le webman au niveau de la page de connection en rejetant l'utilisateur créer s'il tente la connection, mais à chaque MAJ, il faudra le refaire, c'est la seule solution propre qui ne sera pas affecter à chaque modification de droit. Tu peux soumettre l'idée à synology par contre ;-)

Chez moi le débit se divise littéralement en 2 en wifi, genre au lieu d'avoir 18mo/s en téléchargeant du nas, je suis à 9mo/s (wifi ac sur iPhone 6+), sa tombe à 3mo en wifi N, finalement logique vue que tu un le proxy qui fait relay. Maintenant avec un download de 1,5mo/s je suis pas ralenti dans les deux cas, test un téléchargement via ds file et regarde le débit que tu as. Quand il y a des problèmes de connection oui le proxy t'informe qu'il n'a pas établie de connection ou autre avec l'erreur et le mail que tu as mis dans les réglages, perso j'ai déjà eu une ou deux fois pour des sites fermés ou temporairement indisponible.

Et bien si tu as viré tous les droits d'applications, l'utilisateur se connectant n'a accès à rien au niveau de l'interface...

Hum cest chelou, peu être cela vient t'il directement d'ovh, système automatique antipub/spam, essaye de modifier totalement un message type dans avancer et fait en sorte de te faire notifier, si tu le reçois, c'est bien ça.

Ahhh ba voilà si tu nous dit pas tout =) Tu as donc fait l'utilisateur en ssh, il bien après c'est du réglage à faire... Maintenant le plus logique et plus simple... La création via l'interface web et de restreindre ce compte directement...

Question bête, ta vérifier tes spam ? Car si sa marche avec Google c'est pas un problème du nas... Et à te lire ta pas modifier le pass du compte... Donc je vois que ça ;-)

Merci pour le retour, oui c'est un peu déconcertant cette méthode d'écrasement et suppression que le synology pratique au reboot et mise à jour, mais finalement cela évite un encombrement inutile que le syno ou nous même pratiquons, un ccleaner pour toujours être au top et bien stable ^^'

Ahhh oui effectivement vue sous cette angle (la fatigue) Oui c'est tout à fait possible de définir sur le même principe une nouvelle liste acl avec une règle always_direct, qui ne passera pas par le proxy. acl cleanservers dstdom_regex "/volume1/EMPLACEMENT/cleanservers.reg" always_direct allow cleanservers Intègre cela à la suite comme tu as fait pour le tutoriel, ensuite regarde la syntaxe des adresses pour le cleanservers.reg via adservers.reg Si je ne me suis pas trompé cela devrait être bon, j'attends ton retour Voilà ;-)

Sa roule, faut une MAJ aussi pour maintenant =P

Non c'est inutile, pour ma part il est uniquement local, je l'utilise aussi quand je suis connecté au vpn Une whitelist ? Par defaut les seuls blocages proviennent de cette modification antipub

Euh tu parle de quel utilisateur system la ?

Ouaip, tu peux modifier ou rajouter, chaque MAJ purge aussi bien les dossiers normaux que defaut, comportement illogique... Mais bon

Tp-link archer D5 et +

De mémoire, aussi malheureusement :S

Tu veux dire bloquer sont démarrage lors du reboot ? Le soucis c'est que chaque MAJ écrase les modifications faites (rc.d), j'y avais pensé t'inquiète ^^

Bonjour, Pour ma part ma vidéothèque se trouve dans un dossier crypté qui est indexé, malheureusement à chaque MAJ... Son reboot et donc une re indexation... Je vous propose donc deux petits scripts, le premier pour la sauvegarde de la base de donnée avant reboot et celui de la restauration après le reboot, il va de soit de ne pas effectuer de modification au niveau des dossiers indexés entre les deux. Je les exécute pour ma part via le gestionnaire des tâches, ce qui évite une exécution via ssh et je programme une sauvegarde journalière de la base pour ma part. (Pour le cas où une coupure dure et que le synology se coupe..) Ne pas oublier de modifier EMPLACEMENT dans les scripts. backupmedia.sh : #!/bin/sh cd /volume1/EMPLACEMENT rm mediaserver.sql /usr/syno/pgsql/bin/pg_dump -U postgres -C -F p -b -v -f /volume1/EMPLACEMENT/mediaserver.sql mediaserver exit 0 restoremedia.sh : #!/bin/sh cd /var/spool rm syno_indexing_queue* killall synoindexd killall synoindexscand /var/packages/MediaServer/scripts/start-stop-status stop /usr/syno/pgsql/bin/dropdb -U postgres mediaserver /usr/syno/pgsql/bin/psql -U postgres -d template1 -f /volume1/EMPLACEMENT/mediaserver.sql /var/packages/MediaServer/scripts/start-stop-status start rm syno_indexing_queue* killall synoindexd killall synoindexscand exit 0 Un petit partage, pour ma part j'en avais marre de me taper plus d'une journée de re indexation à chaque MAJ, surtout qu'en ce moment ça y va... Donc autant partager ;-)

C'est ce que je disais, déplace le dossier phpmyadmin et crée un sous domaine pour y accéder ;-)

J'avais pas de problème avec le mien, maintenant si phpmyadmin est directement dans un sous dossier de ton site principale, ton htaccess l'impact et forcément ta sécurité ne peux qu'en pâtir. Chaque site son dossier, son htaccess, ensuite on passe par les sous domaine ;-)