lordtaki

Cloudstation bouffe rapidement avec la gestion de versions. Il y a déjà plusieurs threads à ce sujet dans la partie réservée à cette application.

Le message est assez explicite, certains services dépendent de WebStation et ne fonctionneront pas sans celui-ci. Quels sont les services actifs?

DS413 OK.

Un lien en dur ne va pas se voir comme un lien sysmbolique avec la commande 'ls'. http://unix.stackexchange.com/questions/167610/determining-if-a-file-is-a-hard-link-or-symbolic-link if [ "$(stat -c %h -- "$file")" -gt 1 ]; then echo "File has more than one name." fi

J'ai du mal à comprendre l'utilité puisque DownloadStation utilise déjà des liens durs entre le fichier téléchargé (visible dans le répertoire de destination de DownloadStation) et le fichier seedé (celui nommé dans ce thread comme 'caché'). Donc ceci "Ce qui fait que l'on se retrouve avec le double des données utilisées sur le disque.... " est faux. Le fichier existe à 2 endroits différents mais l'espace occupé n'est pas doublé.

Le fichier téléchargé existe à 2 endroits différents via un lien dur (pas symbolique), cela évite de multiplier par 2 l'occupation disque (entre autre) et d'être transparent pour l'utilisateur en cas de renommage/suppression du fichier téléchargé (celui visible via FileStation par exemple). /volume1/@download/.../fichier_telecharge (répertoire DownloadStation) /volume1/../complet/fichier_telecharge (répertoire de téléchargement complété)

pas certain que la redirection de sortie fonctionne... screen -L (on lance screen et on loggue, il y aura un fichier créé automatiquement) ta_commande CTRL-a (en même temps) suivi de la touche d (sortir du screen) screen -ls pour lister les screens en cours screen -r pour récupérer un screen

nohup la commande ou dans un screen.

Ou éditer chaque torrent (clic droit clic).

Il faut se connecter en ssh et l'utilisateur utilisé pour se connecter doit évidemment avoir les droits suffisants pour écrire dans les dits répertoires. cd /volume1/dossier_b ln -s /volume1/dossier_a/dossier_c (lien symbolique) ls -l lrwxrwxrwx 1 user group 22 7 déc. 09:02 dossier_c -> /volume1/dossier_a/dossier_c Et autant pour moi j'avais oublié qu'on ne pouvait pas faire un lien en dur pour un répertoire

Oui c'est possible, il faut faire un lien (symbolique ou en dur).

Quelle taille le fichier?

Vous l'utilisez sans le savoir. Certaines applications Synology se basent sur Postgresql en base de données (Download Station par exemple). Il faut donc bien activer ce service. en ligne de commande: sudo si besoin synoservice --restart pgsql

Pour finir sur le sujet, une simple modification du plugin de recherche suffit: $ext = 'ch'; => $ext = 'li'; dans le fichier /volume1/web/t411.syno.php

Quelle est la configuration du volume? SHR? RAID? Au pire une capture d'écran.

L'idée n'est pas d'empêcher qui que ce soit de faire une préparation des disques. Cependant si c'était un prérequis nécessaire comme vous dites, tous les professionnels le feraient. La passion fait qu'ici certains membres sont bien plus précautionneux qu'HAL (un exemple parmai d'autrs grands noms de l'informatique). :)

La préparation des disques... Pour mon NAS je ne l'ai pas fait et certains disques y ont survécu (c'était il y a 3 ans). A titre professionnel, en 15 ans et plusieurs grands noms de l'hébergement web et/ou FAI, je n'ai jamais vu/lu/entendu les techniciens préposés à l'installation des serveurs ou des baies de stockage faire une préparation des disques.

Effectivement en bidirectionnel c'est plus compliqué. De mémoire Synology propose une solution de backup vers un autre NAS, mais je suppose que ce sera unidirectionnel comme rsync. Si le volume de fichiers est faible, tenter d'utiliser Cloud Station, mais même sans versionning on mange lentement mais sûrement du disque. Sinon: - je suis à Nice (comme moi d'ailleurs), j'active une tâche planifiée (cronjob) qui fait un rsync (mode archive) vers le NAS de Nantes - je suis à Nantes (connais pas), je désactive la tâche planifiée du Nas à Nice et j'active la tâche équivalente sur le NAS de Nantes Il y a une contrainte manuelle, potentiellement source d'erreur.

Déjà vérifier la configuration du client WinSCP, dans la fenere de gestion des sessions: - cliquer sur "Editer" - cliquer sur "Avancé" - dans le sous-menu "Environnement" sélectionner "Répertoires" et vérifier les paramètres "Se souvenir des derniers répertoires", "Répertoire distant" Si ce n'est pas le problème, une fois connecté: - soit cliquer sur le répertoire spécial ".." qui remontre d'un cran dans l'aborescence, autant de fois que nécessaire pour remonter à la racine "/" - soit cliquer directement sur le nom du chemin distant, une fenêtre s'ouvre et renseigner "/"

Un certain nombre de paquets Synology se basent effectivement sur une base Postgresql. Le message "Mise à niveau de la base de données Réessayez ultérieurement" est assez explicite d'ailleurs. Avant toute chose, si cela fait des heures que la situation est ainsi je dirais de relancer le NAS. Normalement postgresql devrait démarrer automatiquement. Si vous êtes un utilisateur avancé, faire un status du service postgresql et selon stop/start (n'ayant pas la main à distance sur mon NAS je ne peux pas donner le chemin complet faire le script qui gère le service postgresql).

Se connecter en SSH au NAS (il y a des tonnes de tutoriels selon l'OS de l'utilisateur). Ensuite: - which mysqldump => cherche mysqldump dans les répertoires listés dans la variable d'environnement PATH - echo $PATH => affiche justement le contenu de la variable PATH - si which ne renvoie rien, le binaire mysqldump est ailleurs sur le système - méthode bourrin => find / -type f -name mysqldump => cherche dans tout le système (/, la racine) un fichier (f) qui se nomme exactement mysqldump Pour gagner du temps sur les futures recherches? Installer locate via les dépôts alternatifs.

J'avais fait le même constat il y a quelques semaines. Modifier le versioning ne permet pas de récupérer cet espace. Lorsque j'ai désinstallé cloud station, le répertoire @cloudstation était toujours présent et toujorus aussi gros. Je l'ai renommé en .old (au cas où), réinstallé cloud station. Une fois validé, j'ai supprimé @cloustation.old.

Sur le poste client (donc pas le NAS): ls -al /home/spectre59/.ssh/ Je n'ai pas l'impression que ta clé privée soit détectée.

ou alors inclure avec une iframe mais bof... Pas d'adresse IP? Il faut un nom de domaine.

J'ai eu le même problème pour un seagate 3To (label desktop pas nas). Le disque était défectueux au déballage, cela arrive, retour SAV auprès du vendeur (à privilégier, le SAV de seagate envoie en retour un disque reconditionné).