gaetan.cambier

dans ce cas, ca simplifie le problème du jbod vu que tu as des volume separés pour le reste, suis donc ce qui avait ete dis en ignorant les etape jbod

en fait, rien de très original : pasage en mode debug : syno_poweroff_task -d on agrandis la partition sfdisk -N3 -z-1 /dev/sda reboot du syno : init 6 pasage en mode debug : syno_poweroff_task -d verification du système de fichier (optionnel) e2fsck -f -y -v -C 0 /dev/sda3 extention du système de fichier : resize2fs /dev/sda3 reboot pour revenir au syno init 6

j'avais du raté ce post à l'origine

Q1: pas réutilisable enfin, pas dans de bonnes conditions Q2: c'est pas de l'exfat sur le nas mais du raid(mdadm) + lvm + ext4. Aucun soft ne le lis, faut passer par un linux Q3: le hotswap est disponible sur le n'as, autant le faire Q3.1: https://help.synology.com/dsm/?section=DSM&version=5.2&link=StorageManager%2Fvolume_diskgroup_expand_replace_disk.html Q3.2: Chez syno, le disk1 est toujours à gauche

[ 30.765961] ata1: device plugged sstatus 0x1 [ 30.770240] ata1: EH pending after 5 tries, giving up [ 30.775297] ata1: detect abnormal stat 0x0 [ 30.779393] ata1: do deep tries 1 [ 30.782713] ata1: not support deep sleep, do one more detect try [ 30.788726] ata1: device plugged sstatus 0x1 [ 30.793011] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4040000 action 0xe frozen t1 [ 30.800661] ata1: irq_stat 0x00000040, connection status changed [ 30.806665] ata1: SError: { CommWake DevExch } [ 30.811117] ata1: hard resetting link [ 33.018323] ata1: SATA link down (SStatus 1 SControl 300) [ 33.018520] ata1: device plugged sstatus 0x1 [ 33.028013] ata1: device plugged sstatus 0x1 [ 33.032291] ata1: EH pending after 5 tries, giving up [ 33.037347] ata1: detect abnormal stat 0x0 [ 33.041443] ata1: send port disabled event [ 33.045545] ata1: EH complete donc, il detecte effectivement l'insertion d'un disque, mais apparemment, le disque renvoit un status anormal et après, le port est désactivé très probablement un disque defectueux a tester sur une autre machine pour etre sur

l'article est accessible à tous

le compatibilité avec des secteur de 4ko, c'est purrement logiciel, et dsm 5.X les reconnait le problème doit etre ailleur --> tester le disque sur un pc pour voir ce qui est bizarre, c'est que si la led du hdd est active, tu devrait le voir pour tester, tu pourrait enlever puis remettre le disque et lancé cett commande jen ssh uste après : dmesg et posté le resultat (tu devrait d'aileur voir un evenement sur l'insertion d'un disque)

C possible, mais faudra ensuite agrandir les partitions Clone les Disk, et ensuite reviens, je donnerai les commandes ;)

Tu l'a dans l'interface du dsm dans sécurité si je me souvient bien

mise à jour très lente, mais ok

Bon, ça règle pas le problème que le n'as à sûrement été mis en dmz, sans quoi ses messages j'arriverai même pas

"man iptables" evidemment, si tu cherche une interface graphique, tu risque d'etre decu

À la fois plus sérieusement, il me semble que tu sais récupérer le rapport sur les doublon donc tu peux faire ton propre script de suppression

Une fonction random pour l'élimination :p

à la fois, si le routeur n'a pas de port forwarding configuré, et que quickconnect est désactivé, la connection depuis internet vers le nas sera difficile

c pas compliqué : syno_poweroff_task -d vgchange -ay lvdisplay | grep " LV Name" la dernière ligne te donne les chemins d'acces du système de fichier à utiliser dans les commandes suivante : pour vérifier le système de fichier : fsck.ext4 -pvf -C0 /path/to/LVName si il y a des problème, voici la commande pour corrigé les erreurs fsck.ext4 -yvf -C0 /path/to/LVName

si tu autorise tout le trafic sur le port 25, il semble logique que des petit plaisantin essaye de s'y connecter : ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25

en effet, c'est pas l'apache du nas, p-e que cela vient d'un container docker ?

Tu peux, il y a aucun problème

Pour cloud station faut utiliser haproxy en mode tcp

J'ai pas suivi, c'est le site ou l'application qui a été modifié pour que ça fonctionne ?

si je comprend bien sur le syno en fait, il y a : les permission de partage (actives uniquement via un partage reseau) les permission du système de fichier (active dans tous les cas à chaque accès au système de fichier) donc, le 2° type de permission est + sur et complet si les permission sur le système de fichier sont bien placées, tu peux meme autorisé tous le monde dans les persission de partage, les acl feront leur boulot ca evite ainsi d'avoir 2 niveau avec les erreur habituelle que les 2 niveau de permission de soit pas cohérentes

N'oublie pas que c'est la panne du raid, pas la panne d'un Disk qui est beaucoup plus fréquente. La formule prend en compte l'URE (unrecoveravle read error) le temps moyen avant qu'un disque soit mort (mtbf) et le nombre de disques Après, c'est du calcul ;)

Non, purement statistique

bon : tu modifie ton conteneur: tu note comme port : 8443 443 tcp et puis tu peux y acceder avec l'adresse : https://ipdunas:8443