Mic13710

Ben oui, vous l'avez même lancé 2 fois ! Regardez les deux premières lignes ...... PID 10957 et PID 11073

Alors on change. Lancez la commande top qui liste les processus en cours. Relevez le PID du processus dd, puis vous tapez q pour quitter top et vous lancez la commande comme je vous l'ai donnée au #47

Désolé. Tapez simplement ps aux | less pour avoir le liste des processus

Oui. Pas d'affolement. Si vous voulez voir la progression, il faut se logger sur un autre terminal et vous entrez la commande ps aux | grep dd qui va vous donner la liste et les PID des processus en cours dans laquelle vous trouverez le processus dd. Il ne vous reste plus qu'à rentrer la commande suivante : kill -USR1 '+ PID du processus dd' qui vous donnera le nombre de record in et record out. Par exemple si le numéro indiqué est le 1154, vous mettrez : kill -USR1 1154

Vérifier si ce n'est pas un pb de carte mère. Procédure ici.

avez-vous suivi "précisément" les informations concernant la connexion en ssh ? le nom du compte a son importance. edit : Pour répondre à votre mp, il ne faut surtout pas ouvrir le port 22 sur la box. L'ouverture des ports c'est seulement pour les accès extérieurs. Il faut simplement activer le terminal ssh et vérifier que le port du ssh (22 par défaut) n'est pas bloqué par le parefeu du nas.

Pas vraiment. Imaginez que tous vos utilisateurs s'amusent à créer des dossiers à tout va et à qui mieux mieux, votre NAS deviendrait rapidement un poubelle ingérable. Relisez ce que j'explique plus haut concernant l'espace disque. Mieux vaut tout de même garder le contrôle. Je vous conseille d'ailleurs d'attribuer des quotas à chaque utilisateur pour ne pas vous retrouver avec des volumes trop rapidement pleins.

Non, le nas peut rester en opération pendant le test. Vous pouvez lancer les tests sur 2 disques à la fois dans les slots 3 et 4. Les disques seront respectivement les sdc (slot 3) et sdd (slot 4). Vérifiez bien vos commandes avant de valider, sinon vous risqueriez d'effacer les disques existants ! Pour la destruction des partitions, tout dépend de ce que donne la première instruction grep "[sh]d." /proc/partitions Vous trouverez obligatoirement sda, sda1, sda2, sda3, sdb, sdb1, sdb2, sdb3 qui sont vos deux disques en opération. Si vous n'avez que sdc (ou sdd) sans sdc1, sdc2 et sdc3 (sdd1, sdd2, sdd3), c'est que le disque n'est pas partitionné. Sinon, il va falloir utiliser la dernière commande qui sera dans votre cas : dd if=/dev/zero of=/dev/sdc bs=512 count=1 (pour le disque 3) dd if=/dev/zero of=/dev/sdd bs=512 count=1 (pour le disque 4) et redémarrer le NAS pour que le nouvel état des disques soit pris en compte. Pour la préparation de vos disques, les commandes sont les suivantes : dd if=/dev/zero of=/dev/sdc bs=1M & (préparation du disque 3) dd if=/dev/zero of=/dev/sdd bs=1M & (préparation du disque 4) Faite bien attention à la lettre du disque (pas de a ni de b dans votre cas !)

C'est ce que j'explique depuis le début. Il ne peut le mettre que dans le périmètre du Cloud que vous avez défini côté serveur. Dans le cas présent, soit il le déplace dans l'un des dossiers Cloud (mes documents ou logistique), soit vous lui créez un dossier partagé "archive" sur lequel il est le seul à avoir les droits.

Si vous aviez lu tout le fil, vous auriez vu qu'au #34 je donne un lien vers un autre fil où j'explique la procédure.

Si vous n'avez pas désactivé le versionning dans CloudStation, vous pouvez aussi récupérer les fichiers qui ont été supprimés.

Je ne comprends pas quel est votre problème. Pouvez-vous m'expliquer ceci : "J'arrive a synchroniser un nouveau dossier pris au hasard sur mon PC dans le dossier CloudStation". Est-ce un dossier que vous avez déplacé dans CloudStation ? Est-ce un dossier partagé dans le NAS ? Vous pouvez mettre dans le Cloud autant de dossiers partagés que vous le souhaitez (s'il y a une limitation, je ne la connais pas), mais pour que ce dossier partagé puisse être intégré au Cloud, il faut : Qu'il soit existant dans le NAS (vous ne pouvez pas le faire à partir de votre PC, c'est dans le DSM que ça se passe) Que l'utilisateur ait les droits sur ce dossier Que ce dossier soit intégré dans CloudStation serveur. Je parle bien de dossier partagé et non d'un dossier qui serait rajouté dans le dossier principal CloudStation de l'utilisateur.

La synchro se fait dans les 2 sens (normal pour une synchro). Tout fichier ou dossier ajouté au dossier principal CloudStation ou dans un des dossiers partagés dans le périmètre du Cloud est ajouté sur tous les cloud : le serveur et les clients. Il est bien évident que tous les dossiers et fichiers à l'extérieur du périmètre ne sont pas synchronisés. Si un utilisateur veut synchroniser un nouveau dossier, il le crée dans le dossier CloudStation, s'il veut synchroniser un dossier existant, il faut le déplacer dans le dossier principal du Cloud. A moins que les dossiers 1 et 2 ne soient des dossiers partagés inclus dans le serveur Cloud, il n'est pas possible de les synchroniser. Le Cloud serveur et le Cloud client ont des contenus identiques, et donc vous ne pourrez pas non plus combiner des dossiers séparés dans un seul dossier.

Et pourtant si. Poser plusieurs fois la même question dans plusieurs fils perturbe le travail de ceux qui donnent de leur temps pour répondre. On peut développer mais je n'en n'ai guère l'envie. Maintenant, faire le choix entre une écriture de zéro ou badblock, si vous lisez le fil (et pas seulement ma réponse très agacée à Bluma) vous trouverez plusieurs avis pour ou contre l'un ou l'autre. J'ai donné le mien dans une des réponses et il me semble que j'ai proposé une écriture de zéros. Et pour l'avoir testé il y a quelques semaines, je n'affectionne pas particulièrement badblock pour l’extrême lenteur de l'opération. Le principal n'est pas tant la méthode utilisée pour vérifier un disque, c'est surtout de le faire en utilisant un outil qui balayera toute la surface du disque. Et donc, je réitère ma réponse, vous faite l'un ou l'autre, ou les deux, c'est votre choix. Le tout est de s'assurer que le disque est bon pour le service. Et pour compléter, je ne ferai jamais l'erreur de mettre un disque neuf dans un NAS sans l'avoir testé au préalable. Même si ça n'a rien changé sur le fond, est-ce que cette réponse vous convient mieux ?

Le compte personnel est comme son nom l'indique "personnel". Chacun peut y mettre ses propres fichiers et dossiers. Dès lors qu'il s'agit de travail collaboratif, il faut passer par les dossiers partagés (bien qu'on puisse dans l'absolue avoir plusieurs PC connectés au même compte utilisateur). Pour CloudStation, il faut de toute façon un compte utilisateur pour pouvoir définir des droits, que ce compte utilisateur ait les privilèges dans CS serveur, pour qu'on puisse y adosser des dossiers partagés qui ont aussi des privilèges dans CS serveur. On ne peut pas travailler anonymement sur un dossier partagés. Dans votre cas, vous avez 3 types d'utilisateurs : compta, la direction, logistique. Soit vous créez seulement 3 comptes utilisateurs et tous les utilisateurs d'un même compte se connecte avec les mêmes identifiants, soit vous pouvez créer des groupes pour chacun d'eux et lorsque vous créez un utilisateur, vous l'affectez a son groupe. Il faudra dans ce cas que chaque utilisateur ait les privilèges dans CS serveur. Attention, CloudStation est très vorace en espace de stockage du fait du dossier de suivi qui est un dossier caché. Il pèse au minimum autant que la somme de tous les dossiers et fichiers inclus dans le Cloud. En clair, pour chaque Mo dans le Cloud, il faut compter au minimum 2Mo d'espace disque utilisé. Si le versionnining est activé jusqu'à 32 versions (valeur par défaut), l'espace utilisé peut rapidement devenir très important. Il faut en tenir compte pour la mise en place d'un tel paquet à grande échelle.

Vous ne pouvez pas accéder à plusieurs comptes utilisateurs dans une même session. Par contre, vous pouvez accéder aux dossiers partagés. Pour faire ce que vous souhaitez, il faut que le compte compta ne travaille pas sur un dossier home mais sur un dossier partagé. Vous donnez les droits appropriés sur ce dossier à la direction et vous incluez ce dossier dans CloudStation. Ainsi, la direction pourra accéder au Cloud Compta sans que la Compta puisse accéder au Cloud de la direction.

La sauvegarde est une absolue nécessité. Pour ma part, j'utilise un autre NAS sur lequel je fais 2 sauvegardes sur 2 disques différents, une fois par semaine. Je pense que votre problème se situait au niveau de l'IP du NAS. Il y a sans doute eu une coupure et le NAS a pris son IP par défaut qui est bien loin des 192.168.x.x de votre réseau. Peut-être aussi un conflit dans les IP. Avez-vous attribué une IP fixe à votre NAS dans votre routeur et cette adresse est-elle inscrite dans les paramètres réseaux du NAS ? Il est important que l'IP soit réservée côté routeur pour éviter qu'elle soit utilisée par un équipement autre que le NAS. Ce qui m'étonne tout de même, c'est que le reset n'ait pas fonctionné. Enfin, l'essentiel c'est que tout soit rentré dans l'ordre.

Bizarre que le reset soit inopérant. Si rien ne fonctionne, il ne vous reste plus que l'arrêt à la sauvage. Débranchez d'abord le câble Ethernet pour être sûr d'être isolé du réseau (pas d'E/S) et après quelques secondes débranchez le connecteur d'alim. Attendez 2 à 3 minutes, rebranchez l'alim et essayez de redémarrer.

Etes-vous sûr que le reset ne fonctionne pas (procédure ici) ? Avez-vous essayé de changer le câble réseau ?

Accès possible via ftp. ftp://utilisateur@nomdedomaine:portftp/home/emplacementdufichier/nomdufichier.kdbx Il faut bien entendu que le port choisi pour le ftp soit dirigé vers le port ftp du nas

Entre nous, ça ne me dérange pas plus que ça : je n'utilise pas Quickconnect

OK. Vous obtenez donc une adresse de type http://gofile.me/xxxxxxx/yyyyyyy et cette adresse est utilisable directement sur un forum ?

Lorsque vous créez un lien de partage dans File Station (clic droit sur le fichier, puis tout en bas "Partager les liens de fichier") vous créez une adresse qui dirigera l'utilisateur vers le fichier ou le dossier pour lequel vous avez créé le lien. Si vous n'avez pas activé Quickconnect, le lien prend la forme : "http://votreDNS:5000/fbsharing/xKDHtPNL" ou "https://votreDNS:5001/fbsharing/xKDHtPNL", 5000 et 5001 étant les ports par défaut. Si vous avez activé Quickconnect, le lien prend la forme suivante : http://gofile.me/xxxxxxx/yyyyyyy Je ne sais pas s'ils peuvent être directement utilisés sur un forum, je n'ai jamais essayé.

De toute manière, il n'est pas possible de passer d'un RAID0 ou JBOD vers un RAID1 sans perdre toutes les données. Les migrations sont possibles uniquement de basic vers RAID1, de RAID1 vers RAID5 et du 5 vers 6 Si en SHR, d'un SHR monodisque vers un SHR multidisque. Il n'est pas possible pour le moment de migrer d'un SHR vers un SHR2 (équivalent RAID6) Enfin, il n'est pas possible de migrer de RAID vers SHR ni de SHR vers RAID. Donc si vous pensez être passé de SHR vers RAID, c'est hautement improbable.

Il y a deux possibilités : Soit la case n'est pas cochée, et dans ce cas le NAS attend le signal "Batterie faible" de l'onduleur pour enclencher le passage en mode sécurité, soit la case est cochée et on choisi un temps avant le passage en mode sécurité. Ce que je ne sais pas en revanche c'est en choisissant un temps déterminé, si le signal "batterie faible" est toujours opérationnel, ce qui serait tout à fait logique mais je ne peux pas confirmer. En effet, s'il y a eu plusieurs coupures et que la batterie est presque vide, le paramètre temps risque d'être plus long que l'extinction de l'onduleur par le manque de jus de la batterie. Mais je suppose tout de même que les ingés de chez Syno ont intégré ce genre de situation.