Classement

Bonjour, Le topic originel https://www.nas-forum.com/forum/topic/37274-fichier-host-1fichier-host-file-1fichier/ n'étant plus mis à jour par son auteur @Souli, il m'a été demandé de créer un nouveau topic pour retrouver plus facilement l'information. J'ai l'intention de maintenir ce fichier host si certains rencontrent des bugs, donc n'hésitez pas à me poser des questions. Si je ne répond pas sur le forum je suis aussi disponible par email, et mon email est indiqué sur mon compte github. L'ensemble du code est donc disponible sur un repo github : https://github.com/Gizmo091/synology_1fichier_hosting Lient de téléchargement du module premium + access ( utilisant la clé d'api ) 2025-10-07 - 4.6.0 : https://github.com/Gizmo091/synology_1fichier_hosting/raw/refs/heads/main/OneFichierCom(4.6.0).host Changelogs : - 4.6.0 : L’URL du fichier "verify" sur 1fichier, utilisée pour vérifier le bon fonctionnement de la connexion, est récupérée depuis le dépôt GitHub. Comme je n’ai plus de compte premium, cette URL est susceptible de changer régulièrement. - 4.5.0 : Mise en place d'un coutournement lorsque la recuperation du nom du fichier par l'api est impossible - 4.4.0 : Suppression du controle du certificats SSL sur les appels à l'API - 4.3.0 : Définition du nom du fichier de destination dans les informations retournées au DL Station ( evite par exemple les _ indésirables ) - 4.2.0 : Prise en compte des liens avec un token de téléchargement : exemple : https://a-6.1fichier.com/p1058755667 - 4.1.0 : Le endpoint Account : Show n'est plus utilisé pour valider que la clé d'API peut être utilisée , on test plutot sur un fichier dont on connait l'existance (fichier sur mon compte) - 4.0.7 : Code rendu compatible à partir de php 5.6 pour être pleinement rétrocompatible. - 4.0.7 : Code rendu compatible à partir de php 5.6 pour être pleinement rétrocompatible. - 4.0.6 : Correction d'un problème si pas de paramètre passé à la place de l'username et correction d'un problème avec les logs - 4.0.5 : Le code est maintenant compatible php7 (des fonctionnements de php8 avait été inclus auparavant) - 4.0.4 : Ajout de la possibilité d'envoyer les logs sur un serveur externe (pour aider au debug) - 4.0.2 : Ajout de logs pour debugger - 4.0.1 : Utilisation du password pour l'apikey et non l'username - 4.0.0 : Attention, version utilisant l'API donc reservé au premium/access Problèmes connus : - [Corrigé depuis la 4.1.0] Le fait de verifier les identifants retourne parfois une erreur, si vous êtes sur de votre clé d'api, ignorez cette erreur. L'API de 1fichier peut parfois être capricieuse et leur politique de controle des requetes faites à l'API est un peut trop restrictive. L'API retourne alors une erreur de flood meme avec très peu de requete. - Conflit avec alldrebrid : La version 4.3.0 ( et peut être d'autre) du host de alldebrid fait echouter le chargement des fichiers host des autres provider. ( je ne sais pas pourquoi mais je l'ai constaté ). - Verification du login : Depuis le 10 octobre 2025, je n’ai plus de compte premium. Par conséquent, je dois régulièrement télécharger un fichier sur 1fichier et mettre à jour le lien dans le dépôt GitHub pour que la vérification des identifiants fonctionne. Une erreur peut survenir lors de la vérification, mais si vous êtes sûr de votre clé API, les téléchargements ne devraient pas être affectés. Support : Soit sur le forum, soit sur Discord : gizmo091 Informations : - Ce fichier host se configure de la facon suivante : nom d'utilisateur : ce que vous voulez ( mais il ne faut pas que ce soit vide), peut contenir des variables de configurations password : votre apikey , récupérable sur le site de 1fichier : https://1fichier.com/console/params.pl section API Key. Notez la bien car elle ne sera plus visible par la suite, il faudra alors la desactivé et en générer une nouvelle si vous devez la saisir à nouveau. Configurations addionnelles : Le champ username/nom d'utilisateur peut donc contenir un ou plusieur configuration. Elle doivent être saisies de la façon suivante : <parametre1>=<valeur_param1>;<parametre2>=<valeur_param2>;... Paramètres disponibles : - local_log : activable en ajoutant local_log=1 dans le champ username Les fichiers de logs seront écrits dans le répertoire /tmp/1fichier_dot_com , un fichier sera créer par téléchargement avec l'id du lien ( exemple : lien = https://1fichier.com/?kitiwlyogv8uozsnfi&af=3108529, fichier de log = /tmp/1fichier_dot_com/kitiwlyogv8uozsnfi.log ) , si par d'identifiant dans le fichier sera /tmp/1fichier_dot_com/default.log Exemple avec local_log d'activé : - remote_log : activable en ajoutant remote_log=<serveur_de_log> dans le champ username. Les logs seront envoyé au serveur passé en paramètres via des requetes cURL. Vous pouvez heberger votre propre serveur de log en utilisant le code se trouvant dans le repertoire remote_log du repository git, ou alors vous pouvez utiliser mon serveur : https://vedie.fr/remote_log/log.php et vous pouvez consulter les logs ici : https://vedie.fr/remote_log/read.php Exemple avec remote_log d'activé : Hashtags : hostfile, host file, onefichier

Bonjour, Quelqu'un aurait-il un lien pour télécharger un fichier host (download station) pour le site Updloady.io s'il vous plait ? Ou un tuto sur comment en créer un ? J'ai vu sur Google qu'il y avait un topic à ce sujet sur le forum mais je n'y ai pas accès : https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://www.nas-forum.com/forum/topic/81968-fichier-host-pour-uploadyio/%3Fdo%3DfindComment%26comment%3D1319513384&ved=2ahUKEwiKuK_mrpWLAxXZ3AIHHQ3lJ0gQFnoECAcQAQ&usg=AOvVaw1KQ-cOebOdNKcHwwUFaVT8 Merci d'avance

Refonte du tutoriel pour la V6, amélioration du fichier compose et mise à jour des impressions d'écran.

Bonjour à tous, Après une installation réussi hier soir de Bitwarden, je viens vous proposer un petit tuto pour l'installer. Tout d'abord, Bitwarden, qu'es ce que c'est ? Bitwarden est une application Open Source développer en C# et MSSQL (j'y reviendrais) qui permet de gérer ses mots de passe à la manière de 1Password, Lastpast, Keepass. Des extensions sont disponibles pour tout les navigateurs et iOS/Android. Vous aller me dire tout ça c'est bien joli mais quel intérêt ? L’intérêt, c'est qu'il est possible de s'auto héberger et donc d'avoir son propre gestionnaire de mot de passe à la maison sans passer par des serveurs bien plus exposé sur internet. Vous êtes toujours partant ? En premier lieu, quelque pré-requis : - Disposer d'un NAS sous architecture x86 (Intel) tout simplement car l'installation est réalisé avec Docker - Disposer de pas mal de RAM, l'application exécute une instance Microsoft SQL Server (très) gourmande en RAM (environ 700Mo, une version Ruby beaucoup plus légère existe mais c'est une adaptation et non une vrai branche) - Ne pas avoir peur de faire un peu de ligne de commande ? Vous êtes toujours là ? Allons y vous aller voir c'est très simple. Merci @InfoYANN pour avoir refait toute le tuto avec les dernières version de Bitwarden ! ***************************************************** Créer un dossier "bitwarden" dans le dossier "docker" dans FileStation. Créer un sous domaine pour votre instance bitwarden et faites en sorte que le certificat SSL de Let's Encrypt soit fonctionnel (rien à faire pour les certificats wildcard). Aller sur le site de Bitwarden afin d'obtenir un ID : https://bitwarden.com/host Entrer une adresse mail valide et copier : ID d'installation : xxxxxxxxxxxxxxxxxxxxxxxxxxxxx Clé d'installation : xxxxxxxxxxxxxxx Maintenant connecter vous en SSH (voir mon tuto si vous ne savez pas faire). Rendez-vous ici : cd /volumeX/docker/bitwarden Nous allons maintenant récupérer le script d'installation et le mettre dans le dossier bitwarden fraichement créé : curl -s -o bitwarden.sh https://raw.githubusercontent.com/bitwarden/core/master/scripts/bitwarden.sh&& sudo chmod u+x bitwarden.sh Puis on lance l'installation : ./bitwarden.sh install Pendant l'installation, nous allons devoir répondre à quelques questions (moins qu'auparavant) : *Les lignes en rouge seront les messages du système au fur et à mesure de l'installation ! (!) Enter the domain name for your Bitwarden instance (ex. bitwarden.company.com): sousdomaine.domaine.tld (!) Do you want to use Let's Encrypt to generate a free SSL certificate? (y/n): n (!) Enter your installation id (get at https://bitwarden.com/host): xxxxxxxxxxxxxx (!) Enter your installation key: xxxxxxxxxxxxx (!) Do you have a SSL certificate to use? (y/n): y !!!!!!!!!! NOTE !!!!!!!!!! Make sure 'certificate.crt' and 'private.key' are provided in the appropriate directory before running 'start' (see docs for info). (!) Is this a trusted SSL certificate (requires ca.crt, see docs)? (y/n): y Installation complete If you need to make additional configuration changes, you can modify the settings in `./bwdata/config.yml` and then run: `./bitwarden.sh rebuild` or `./bitwarden.sh update` Next steps, run: `./bitwarden.sh start` and then `./bitwarden.sh updatedb` Rendez-vous dans FileStation mais ne fermez pas votre fenêtre SSH. Nous allons renommer et copier les fichiers du certificat SSL dans le bon dossier : Renommer le fichier "privkey.pem" avec comme nom "private.key" puis le copier dans /volumeX/docker/bitwarden/bwdata/ssl/votredomaine/ ce qui donnera comme résultat : /volumeX/docker/bitwarden/bwdata/ssl/votredomaine/private.key Renommer le fichier "cert.pem" avec comme nom "certificate.crt" puis le copier dans /volumeX/docker/bitwarden/bwdata/ssl/votredomaine/ ce qui donnera comme résultat : /volumeX/docker/bitwarden/bwdata/ssl/votredomaine/certificate.crt Renommer le fichier "chain.pem" avec comme nom "ca.crt" puis le copier dans /volumeX/docker/bitwarden/bwdata/ssl/votredomaine/ ce qui donnera comme résultat : /volumeX/docker/bitwarden/bwdata/ssl/votredomaine/ca.crt Nous allons maintenant créer les dossiers qui seront manquants pour la suite de l'installation : /volumeX/docker/bitwarden/bwdata/logs /volumeX/docker/bitwarden/bwdata/logs/admin /volumeX/docker/bitwarden/bwdata/logs/api /volumeX/docker/bitwarden/bwdata/logs/icons /volumeX/docker/bitwarden/bwdata/logs/identity /volumeX/docker/bitwarden/bwdata/logs/mssql /volumeX/docker/bitwarden/bwdata/logs/nginx /volumeX/docker/bitwarden/bwdata/logs/notifications /volumeX/docker/bitwarden/bwdata/logs/events /volumeX/docker/bitwarden/bwdata/core /volumeX/docker/bitwarden/bwdata/core/attachments /volumeX/docker/bitwarden/bwdata/mssql /volumeX/docker/bitwarden/bwdata/mssql/data /volumeX/docker/bitwarden/bwdata/mssql/backups Nous allons éditer le fichier "global.override.env" qui se trouve dans "/volumex/docker/bitwarden/bwdata/env" afin de configurer le serveur SMTP pour que Bitwarden puisse envoyer les notifications. On va en profiter pour inscrire notre adresse mail pour la partie admin 😉 Il faut maintenant finir de configurer manuellement le fichier "config.yml" qui se trouve dans "/volumex/docker/bitwarden/bwdata" : Par défaut, les ports sont 80 et 443 mais en général, ils sont déjà utilisés sur DSM alors on va en mettre d'autres. Pour ma part, j'ai choisi le port 81 et 444. On retourne dans notre fenêtre SSH et on lance ensuite ces commandes une par une : ./bitwarden.sh update ./bitwarden.sh updatedb ./bitwarden.sh start Si ces commandes ne fonctionnent pas, faites d'abord : ./bitwarden.sh rebuild Vous pouvez maintenant accéder à votre instance Bitwarden via votre domaine : le port. Source : http://www.synology-forum.de/showthread.html?90435-Bitwarden-auf-der-Synology-(Docker)/page5 En complément, dans le dossier env (éditable via vi pour les plus aguerris) vous pouvez paramétrer le SMTP (pour l'envoi des mails) et bloquer les inscriptions supplémentaires sur votre serveur ci nécessaire.

Importante mise à jour qui vient de sortir : MàJ faites sur DS220+ et DS218+.

Bonjour, Je viens de voir que dsm 7.3 est en vue. Ce sera la dernière mise à jour pour mon DS 218+ 😞

Autre solution : en IPv6, chaque NAS a sa propre adresse IP publique, et est donc adressable sans souci, sur tous les ports.

Salut @.Shad., Le problème avec les serveurs DNS c'est que leur hiérarchie n'est pas respectée. Le client peut faire appel à n'importe quel serveur de la liste. Si le DHCP distribue plusieurs IP DNS, il vaut mieux que ces serveurs résolvent les requêtes de la même manière. Je suis plutôt pour une deuxième instance pi-hole (ce que j'ai), ou bien à la limite passer par le serveur DNS du NAS avec une zone correctement paramétrée. Surtout pas d'autres serveurs externes qui sont incapables de résoudre les adresses locales.

Hello, j'ai aussi fait la migration il y a quelques semaines et ça s'est très bien passé. Je vais essayer de trouver le temps de mettre à jour le tutoriel, je devrais retrouver des disponibilités à partir de fin juin...

cd /volume1/@appdata Un simple cd / est plus efficace.

Il y a aussi Domoticz que j'utilise sur un Rasp PI4. A mon avis, que ce soit home assistant, jeedom ou domoticz ou d'autres, mieux vaut ne pas solliciter le NAS pour ces applications qui sont en général nativement adaptées et parfaitement intégrées sur des plateformes type Rasp.

Par défaut, un paquet WoL n'est diffusé que sur le segment réseau de l'émetteur. Dans le cas présent, le smartphone n'émet ce paquet que sur le réseau 192.168.68.0/24 (broadcast à destination de 192.168.68.255 ou 255.255.255.255). Le paquet ne peut donc pas parvenir au NAS situé sur un autre segment (192.168.1.0/24). Il est très peu probable que le routeur Mesh propose un proxy WoL pour propager la diffusion du paquet sur les autres segments qui y sont connectés. La solution la plus simple est de connecter le NAS derrière le routeur mesh (attention au changement d'adressage IP). La solution la plus propre est de configurer un unique segment réseau en configurant les appareils réseau du réseau mesh en points d'accès Wi-Fi.

Bonjour, Je n'ai pas tout compris...

Re-bonjour, J'ai trouvé ma réponse : mon mot de passe contient des caractères spéciaux dont la saisie est mal interprétée dans drive client ubuntu. En saisissant le mot de passe dans un éditeur quelconque, puis en le copiant dans le mot de passe de la connexion drive client, Ö miracle, ca fonctionne. bien à vous

Attention toutefois, dans le tuto donné par @firlin, la résistance est à 100ohm. Il faut remplacer cette valeur par 300ohm environ pour limiter le courant dans le transistor (voir ce fil de discussion)

@Sun880 Tu es mal placé pour faire le malin... De plus tu as posté dans une autre rubrique la même question à 2 reprises. Je te laisse une semaine de vacances pour t'approprier le fonctionnement du forum

Tout est vendu !

Click droit sur la touche Windows et lancer l'application Terminal suffit. Puis faire la commande : K.I.S.S.

Donne-moi un seul cas d'usage où un débit >1Gbps sur internet est nécessaire sur ton NAS.

J'ai repris la configuration de sécurité : et cela a visiblement corrigé mon problème...

Bonjour, Comme j'ai fait un retour sur un autre forum bien connu (HFR) sur les nouvelles caméra Reolink RLC-520, je me dis que ce serait une bonne idée de vous en faire profiter ici aussi 😉 Il y a quelques mois j'ai fais l’acquisition d'une RLC 420-5MP, et j'ai récemment commandé deux RLC-520 puisque la 420-5MP a été remplacée par la 520. Je prend un petit risque puisque étant toute récente, elle n'a pas de pilote dans Surveillance Station, malgré un DevicePack à jour. Les deux nouvelles caméras vont être montées sur un Junction Box D20 pour y plaquer les connecteurs car mes murs sont épais (mur de façade de maison). J'ai donc reçu mes supports à caméra et mes deux caméras RCL-520 (qui est une 5MP mais n'a plus la mention vu qu'il n'y a que du 5MP), et avant d'installer ça sur le mur, j'ai posé en vrac dans le garage, a proximité du switch TP-Link PoE. Après le setup via l'application Reolink (qui n'est pas compliqué à faire, mais avec leur application c'est quand même pas super optimal, et pour le coup l'application macOS est mieux que la windows car la windows c'est fullscreen obligatoirement... mais passons...) et la MAJ du firmware pour celui sorti il y a quelques semaines, place à la configuration dans Surveillance Station 🙂 Dans les captures ci-dessous, à gauche se trouve la nouvelle caméra RLC-520 et à droite celle acheté fin décembre, la RLC-420-5MP. Aucun pilote n'est disponible pour ce modèle, contrairement à la 420-5MP... Donc la configuration est avec ONVIF (j'ai fait des captures de comparaison pour voir ce qui change entre la caméra avec pilote et celle sans). (Je n'ai jamais essayé la RLC-420 en ONVIF). Le port de connexion n'est du coup pas le même... (je ne sais pas si le port 8000 de la caméra est sécurisé ou pas... mais comme pour l'autre c'est le port 80 (j'ai essayé les autres de la caméra, et seul le 80 fonctionne pour celle avec pilotes). Ensuite, dans les paramètres vidéos, on ne peut pas régler le bitrate sur une valeur constante, c'est forcément variable. Les FPS sont configurables de la même manière sur les deux. [ Sur la partie optimisation : on perd là quelques réglages... Exit l'orientation de la vidéo par Surveillance station, idem pour l'horodatage et la gestion de l'exposition par SV... Pour la détection de mouvement, la sensibilité disparait, mais elle n'était pas modifiable donc, c'est pas une grande perte. Mais il est toujours possible de laisser la détection aux bons soins de Surveillance Station : (perso je laisse la caméra gérer, tant que je n'ai pas mis en situation les caméras). Voilà voilà. Quelques réglages perdu pour la caméra sans pilote donc en ONVIF. Personnellement, ça ne me gène pas car je n'utilisais pas ces réglages pour l'autre, laissant la caméra gérer elle-même avec ses paramètres. Le client mobile de Reolink est pas trop mal. Maintenant reste à voir comment le NAS va subir cet ajout de 2 caméras à l'existante 😄 j'espère qu'il ne va pas trop ramer... Voilà voilà 🙂 Je ferais quelques photos des caméras quand je les installerai mercredi (je vais chercher du câble réseau chez Leroymerlin ce mercredi). Le modèle 520 est un peu plus petit que le 420-5MP. Une partie est en plastique donc le support de fixation, et c'est selon moi le seul gros défaut de ce modèle... Bon mes caméras vont être à presque 3m de hauteur... ++ Miles