Fenrir

bien vu pour l'encodage, j'aurai du te l'indiquer.

Je pense que tu as assez torturé tes disques. Si avec tout ça aucun outil ne trouve d'erreur, ton pb initiale devrait être corrigé.

Je ne dis pas que c'est la seule solution, je dis que c'est probablement le plus simple. Mais si tu y accède, même lentement, par un autre moyen (quickconnect, ssh, ...), il te suffit de couper le parefeu (temporairement). En passant, n'utilises JAMAIS l'upnp pour configurer un routeur ou un pare feu, c'est une catastrophe ce système (pas spécialement sur les syno, mais de manière générale). Upnp : Universal Plug aNd PRAY

comme ça je dirais pas de bol Si tu as encore accès aux données, fait un backup Par contre tu n'as qu'un disque dans ton RS ?

L'appli sauvegarde et réplication fait très bien ce que tu demandes

La question est plutôt pourquoi utilises tu cygwin pour faire ça ? =>un simple putty (si tu es sous Windows) ou le terminal de base (sur Linux, Unix, Mac, ...) devrait suffire pour faire des sed Ton pb est que ton terminal SSH, ton utilisateur sous cygwin, le nas aussi et ton fichier peuvent chacun avoir leur encodage enlève cygwin de l'équation fais en sorte d'avoir le même encodage de bout en bout (UTF-8 de préférence) ouvre ton fichier avec un vrai éditeur (pas le bloc note), par exemple notepad++

Si je comprends bien : tu sauvegardes sur \\nas\fichiers\scan.pdf => erreur tu sauvegardes sur c: puis du recopie sur \\nas\fichiers\scan.pdf => ok Si tel est le cas, la faute reviens à ton logiciel de scan qui n'arrive pas à écrire correctement sur un chemin réseau. Si tu ne peux pas en changer (de logiciel), tu peux passer par un dossier temporaire sur ton pc et installer un petit soft (ou faire un petit script batch) qui se charge de copier les données de ce dossier vers ton nas

Ça veut dire que ta ligne n'est pas assez qualitative pour se passer de la correction d'erreur (le mode patate supprime les corrections d'erreur, le mode sérénité au contraire en fait plus la normal)

quand tu installe un disque neuf dans le syno, ce dernier te propose de le tester, c'est très long mais ça peut éviter des surprises, à toi de voir les données sont lisibles à mon gout, mais sinon : https://fr.wikipedia.org/wiki/Self-Monitoring,_Analysis_and_Reporting_Technology ça dépend de plein de choses (à quoi il va servir, sa taille, ma patience, ...) ça dépend des outils, en ligne de commande un simple copié collé marche très bien

Quand tu as fait les paramétrages, tu as du louper tes règles de pare feu et te bloquer l'accès depuis ton lan Mais normalement, le syno t'interdit de te couper les pattes quand tu fais ça, donc l'ip d'où tu as fait ces réglages doit être autorisée. =>essaye d'y accéder depuis chez tes parents Pour la double authentification, c'est très bien de l'activer, à une seule condition : avoir activé le SSH (pour pouvoir de débloquer en cas de perte du jeton et de pb de date)

Je viens d'installer tout le bazar (mariadb, haproxy et ttrss) pour faire le test. J'avais oublié que ttrss se servait de l'URL et ne peut donc pas fonctionner (facilement) sur 2 chemins différents (http://tonnas/tt-rss et http://rss.domain.tld/). Au final on va tout de même devoir passer par les vhosts, mais de manière détournée (juste pour changer le port), désolé. Pour l'exemple, je pars du principe que tu souhaites atteindre ton app avec l'url http://rss.domain.tld et que la résolution DNS de rss.domain.tld renvoi l'ip de ton nas (en local tu peux tricher en modifiant ton fichier hosts). dans Web Services, créé une nouvelle instance d'apache sur un port disponible, par exemple sur le port 81 Sub-folder Name: le nom du dossier où est installé tt-rss => tt-rss Hostname: peut importe, il faut juste remplir la case => la.tete.a.toto Protocole: HTTP Port: 81 dans HAProxy, créé un backend : Name: ttrss Servers: ttrss localhost:81 check Options: rien dans HAProxy, créé une association : Frontend: http Backend: ttrss Condition: if { hdr_beg(Host) -i rss. } si tu ne l'as pas fait durant l'installation modifie la directive SELF_URL_PATH du fichier config.php de tt-rss pour indiquer l'adresse completedefine('SELF_URL_PATH', 'http://rss.domain.tld/'); dans ton navigateur, entre l'adresse : http://rss.domain.tld:5080 Chez moi ça fonctionne

il est branché sur un switch ou une box ?

Le SHR n'est qu'un astuce de synology permettant de ne pas perdre trop de place en raid avec des disques de taille différente. En pratique il ajoute juste une couche LVM. C'est surtout utile à partir du raid 5. Dans ton cas ça n'a pas d'importance

ce n'est pas prévu, mais avec un peu d'astuce tu devrais pouvoir le faire (par exemple avec un tâche planifiée qui active/désactive une règle de pare feu bloquant le smtp)

tu es certain qu'il est bien connecté au réseau ? test avec un autre câble reboot ton switch/routeur

Pour la "sécurité" des données : raid1 ET sauvegarde sur un autre support (un disque USB, un autre nas, une offre cloud, ...) Pour la sécurité de l'accès aux données : firewall du nas, anti brute force et mots de passe fort Le VPN est un moyen permettant d’accéder de manière sécurisée aux données depuis l’extérieur (c'est comme ça que j'accède à mon nas depuis mon smartphone), mais si on peut accéder au nas par un autre moyen (port 5000 ouvert par exemple) ou que les mots de passe son faibles, le vpn n'apportera rien

je pense que ça répond à ta question

Tu peux "masquer" le partage photo (ou tout autre partage), il existera toujours, mais ne sera plus affiché

disque physique => couche lvm => couche raid => système de fichier (ext4) => dossiers (/volumeX)

C'est une info importante que j'aurai aimé avoir depuis le début Oui c'est très probablement la cause de tes soucis, tu as du louper ton montage dans le conteneur. Essaye de stopper le conteneur/désactiver (pour qu'il ne démarre plus au reboot) puis reboot ton syno, arrete un maximum de services et exécute directement les commandes (sans faire de cd ou de ls) Si tout se passe bien (que tu as bien tes données dans /volume1 et que tu y accède depuis filestation), reboot, puis fais : du -sh /0bug et post le résultat ici Sinon, ne reboot pas et annule le mv avec mv /0bug/* /.

Pour être franc, il y a peu de chance que le mv casse quoique ce soit, mais comme : tu n'as pas de backup ce n'est pas mon nas encore moins mes données je n'ai presque aucune info sur ce qui a été fait dessus (paquets, custo, ...) je n'ai même pas le modèle et que je n'y ai pas un accès direct je préfère dire que c'est "potentiellement" dangereux, en gros je ne veux pas assumer la moindre responsabilité S'il c'était s'agit de mon nas, j'aurai tapé la commande directement car : avec un accès physique aux disques, je suis presque certain de m'en sortir. j'ai un backup de 100% des données

Tu peux parfaitement placer les droits que tu souhaites sur les dossiers/partages de ton choix. Si tu veux faire ceci, c'est possible : /data : partage accessible à tout le monde /data/public : dossier accessible à tout le monde /data/private : dossier accessible à toi seul /data/public/private : dossier accessible à toi seul dans un dossier accessible à tout le monde (on le droit d'être maso) Tu peux même aller beaucoup plus loin (autoriser l'écriture mais pas la lecture, autoriser les fichiers mais pas les dossiers, ...) C'est juste plus lourd en terme de gestion que de bien ranger ses données et ça limite la compatibilité avec les paquets Synology (PhotoStation par exemple)

Je ne suis pas certain de bien comprendre la question. La réponse rapide est : sur le disque LVM n'est qu'une couche intermédiaire entre le le volume physique et le système de fichier

oui, mais ça c'est une règle générale, à faire surtout quand on n'a pas de problèmes si tu es en raid, oui oui si tu arrive à identifier l'emplacement des secteurs défectueux, tu peux faire des partitions "autour" c'est super pratique pour accrocher les couteau au dessus du plan de travail oui, avec toutes les réserves de rigueur, le disque a déjà eu des soucis, il en aura probablement d'autres

J'ai aussi docker installé avec quelques instances et je n'ai pas de soucis. Essaye ceci : coupes tous les services (smb, nfs, webdav, ...) sauf le ssh arrête toutes les appli/packet (docker, *station, ...) démonte/eject tout ce qui peut l'être (usb, volumes distants, ...) puis en ssh (le danger réside ici, le caractère de contrôle peut avoir une mauvaise interaction avec mv) mkdir /0bug mv /volume1* /0bug/ Normalement ça devrait faire une erreur sur /volume1 (il ne peut pas déplacer un volume monté) et déplacer le dossier /volume1▒ dans /0bug Si tu n'as pas de chance, l'inverse va se produire, il faudra alors renommer le dossier volume1▒ en volume1. Si ça ne corrige pas le problème, on tentera autre chose