CoolRaoul

Je pense avoir récupéré la situation: Apres avoir tenté un mv /usr/syno/etc? /usr/syno/etcX (n'oublions pas que le "?" matche n'importe caractere unique) Je me suis aperçu que maintenant les inodes n'était plus les mêmes: root@fserv> ls -ldi /usr/syno/etc* 139588 drwxr-xr-x 33 root root 4096 2012-09-23 22:54 /usr/syno/etc 41302 drwxr-xr-x 18 root root 4096 2012-09-01 10:45 /usr/syno/etc.defaults 17045 drwxr-xr-x 4 root root 4096 2012-09-23 22:29 /usr/syno/etcX [/code] (139588 et 17045) donc a priori je n'ai plus de répertoire doublement linké Quand j'aurais le temps je ferai une vérification plus globale. PS: tout ça m'a permis de faire joujou avec la commande "debugfs" que je n'avais pas pratiqué jusqu'ici.

les grand esprits se rencontrent

Surtout pas malheureux!!! Tout ce qui est sous les deux répertoires ("etc" et ... l'autre) sont strictement les memes fichiers et répertoires. Le rm va tout casser! Fait bien comprendre qu'il s'agit ici d'un hardlink de répertoires, ce qui ne devrait jamais arriver (sauf pour les "." et les ".." bien entendu)

Tu peux déja utiliser le firewall du syno (ou celui de ton routeur) et autoriser ssh qu'a partir d'IPs *connues* (de toi s'entend)

M'arrive un truc étrange J'ai dans le répertoire /usr/syno une deuxième entrée de répertoire doublon de "etc" (avec le meme inode donc) avec un caractere étrange: root@fserv> cd /usr/syno root@fserv> /bin/ls -lid etc* 17045 drwxr-xr-x 3 root root 4096 Sep 11 16:36 etc 41302 drwxr-xr-x 18 root root 4096 Sep 1 10:45 etc.defaults 17045 drwxr-xr-x 3 root root 4096 Sep 11 16:36 etc\302 j'ai bien entendu essayé avec le unlink d'optware: root@fserv> unlink etc? unlink: cannot unlink `etc\302': Is a directory ainsi qu'avec "rm -d" (toujours optware) root@fserv> rm -d etc? rm: cannot remove `etc\302': Is a directory En fait il semble bien que l'appel systeme "unlink" échoue sur un répertroie meme en étant root (un petit programme C ad hoc me l'a démontré) Si quelqu'un avait une idée pour corriger ça de façon "chirurgicale" ça m'arrangerait bien

Je ne comprend pas pourquoi, dans le tuto que tu utilises, on demande de ne pas installer le mkvtoolnix officiel pour la raison foireuse "celui-ci n’a pas fonctionné pour moi (manque de dépendances)." étant donné qu'un des roles d'un gestionnaire de packages comme ipkg est d'assurer la résolution des dépendances! En outre, récupérer un package sur un site inconnu et ensuite forcer l'install en bidouillant le MD5, franchement j'ai des réticences. D'autant plus qu'il suffit de : root@fserv> ipkg install mkvtoolnix Installing mkvtoolnix (4.2.0-1) to root... Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable/mkvtoolnix_4.2.0-1_arm.ipk Installing boost-regex (1_45_0-1) to root... Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable/boost-regex_1_45_0-1_arm.ipk Installing libebml (1.0.0-1) to root... Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable/libebml_1.0.0-1_arm.ipk Installing libmatroska (1.0.0-1) to root... Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable/libmatroska_1.0.0-1_arm.ipk Installing lzo (2.03-1) to root... Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable/lzo_2.03-1_arm.ipk Configuring boost-regex Configuring libebml Configuring libmatroska Configuring lzo Configuring mkvtoolnix Successfully terminated. et voila le mkvtoolnix "officiel" de optware installé. Ben c'est DSM, (et le mot distrib est un peu innaproprié puisqu'elle n'est pas distribué a proprement parler puisque reservé aux matériels Synology). et c'est basé sur un busybox PS: je persiste a croire que t'em***r comme on le constate pour installer mkvtoolnix sur don ds212 alors que ca existe sous Windows et MacOS et, qu'étant donné le rapport de perfs brutes en un PC moyen et ton NAS, ca tournera *beaucoup* plus vite, à moins que ce ne soit que pour le fun, je ne vois pas l'intéret.

Comme tu as du sans doute le deviner, la réponse (ou plutôt la solution) est donc; chmod a+rx /var/lib[/code] Maintenant faudrait quand même savoir comment des modes aussi fermés ("rwx------") ont bien pu arriver sur /var/lib et si par malchance d'autres répertoires systèmes n'ont pas également été modifiés dans l'opération.

ah tiens , bizarre, peut-être une limite de VideoStation à 7 jours De toutes façon, le produit est encore jeune, faut bien accepter quelques dysfonctionnements.

voila autre chose, Ou et à quel moment apparaît ce message?

En ce qui concerne le script, il se contente de modifier le contenu du répertoire "/usr/syno/etc/packages/VideoStation/EPG" et rien d'autre Faut chercher le coupable ailleurs je pense.

Ben essaye... ton NAS ne va pas s'autodétruire

La gamme Xstreamer m'a l'air bien sympa aussi. Voici une petite sélection, pré-filtrée chez les nums: http://www.lesnumeri...6=v9,v80&dav=12

ca ce n'est pas normal, le login est refusé ou tu sort en timeout? tu as gardé l'acces ssh j'espère? ***EDIT** quel tuto as-tu suivi pour l'install de optware ? (note: "ipkg" est simplement la commande pour ajouter/supprimer les packages optware)

D'apres google, le mot "rsync" n'apparait dans aucune des pages de leur site... Il y a peu d'espoir à priori. Tu peux toujours contater leur assistance, juste demander si rsync est supporté dans le cadre de leur offre "Stockage en ligne". Tu ne risques rien apres tout. Au passage tu constatera qu'ils ne semblent pas supporter ftp mais seulement sftp (ce qui n'est *pas* la même chose) Si tu veux mon avis, choisir un prestataire de solution de sauvegarde en ligne qui ne supporte qu'un seul protocole (sftp), ça n'est pas un choix optimal, mais j'imagine que c'est trop tard pour changer.

Essaie ceci maintenant: ls -ld /var/lib /var /[/code]

que donne ls -ld /var/lib/postfix/[/CODE] ?

Plus en ligne??? ***EDIT*** Oups, en effet ... zut Il y a bien ceci sinon: http://synologeek.dyndns-free.com/2012/04/14/comment-se-connecter-en-ssh-sur-synology/

Sinon, tu as "mkvmerge" qui fait partie de mkvtoolnix, qui existe sous windows, et fait ça tres bien. **EDIT** Handbrake (https://trac.handbrake.fr/) n'est pas mal non plus

Ah oui en effet , c'est pas faux.

La c'est juste le "grep master" qui se trouve lui-meme essaie /usr/syno/bin/synopkg stop MailServer suivi de /usr/syno/bin/synopkg start MailServer [/code] donne-nous tout message apparaissant à l'écran et dans les logs apres apparu *apres* ces deux commandes

Connait pas mais si ca marche tant mieux

"dossier partagé" dans le panneau de conf, tout simplement! Mais j'ai du mal a comprendre: Dans ton 1er message tu nous disais avoir des problèmes pour accéder au "répertoires usr " que tu donnais comme exemple et ne pas avoir de problème pour accéder au "répertoire du volume 1" par contre (lequel?) Juste apres on apprend qu'en fait, les fichiers auquels tu veux accéder sont "dans des répertoires en dessous de Volume1" (pourquoi nous avoir parlé de "usr" alors?) Faudait savoir! Donc, ou sont *exactement* ces fichers? Si ils sont dans un dossier sous "/volume1/<nom>" il suffit d'activer le partage de ce dernier dans le panneau de conf et c'est tout (en mettant les droits qui vont bien)

tout est expliqué ici:

En standard sous DSM, tu as un client "wget" qui sait faire du ftp: il est dans "/usr/syno/bin/wget" il est possible que ça réponde à ton besoin: root@fserv> /usr/syno/bin/wget --help GNU Wget 1.10.1, a non-interactive network retriever. Usage: wget [OPTION]... [URL]... /../ FTP options: --ftp-user=USER set ftp user to USER. --ftp-password=PASS set ftp password to PASS. --no-remove-listing don't remove `.listing' files. --no-glob turn off FTP file name globbing. --no-passive-ftp disable the "passive" transfer mode. --retr-symlinks when recursing, get linked-to files (not dir). --preserve-permissions preserve remote file permissions.