Diaoul

Et /etc/shells ? Sent from my Desire HD

Bien vu. Sent from my Desire HD

C'est bien de vouloir rester avec du natif mais tu vas vite

Je te passe mon script pour que tu puisses voir dans la journ

C'est bizarre, je suis s

Je pense qu'il serait bon de pouvoir s

Non la config est

En effet depuis une certaine mise

A la fin du script tu peux faire un chmod -R 777 /volume1/netbackup/ovh Ça aura pour effet de mettre toutes les permissions sur les fichiers téléchargés. Ou alors, au début du script, peut être avec un umask 0000 C'est plus "optimisé" C'est extrêmement permissif mais c'est ce que fait le Syno par défaut donc bon..

C'est du x86 tu trouveras

Remettre un disque dur dans un RAID 5 "en panne" et lancer la reconstruction est-il bien différent que de remettre un disque dur et lancer la reconstruction d'un RAID 1 ? Partons du principe que tu possèdes 4 disques même marque et de même modèle. Le seul moment ou tu gagnes en sûreté quand tu fais 2 x RAID 1 plutôt que 1 x RAID 5 c'est en cas de double panne simultanée. Panne de 2 disques dur simultanément : 2 x RAID 1 = Au mieux rien de perdu, au pire 50% des données 1 x RAID 5 = Tout perdu dans tous les cas En cas d'une panne de disque dur, RAID 5 = RAID 1. Et il faut bien noter que le RAID 5 est plus économique que le 2 x RAID 1 pour un même espace de stockage utile. Pour avoir une tolérance de panne à 2 disques durs, il faut se pencher sur le RAID 6. Économiquement équivalent au double RAID 1 dans le cas d'une grappe de 4 disques.

En fait ça ne pourra jamais marché sur nos Synos cette fonction. Peu importe les droits, ce n'est pas là le problème. Le problème c'est que nobody, l'utilisateur qui gère le serveur web de nos Syno, n'a pas, et n'aura jamais, les droits suffisants pour arrêter un processus lancé par un autre utilisateur. On ne peut pas lancer nzbget avec le même utilisateur que le serveur web parce que dans ce cas, les fichiers créés par nzbget auraient un propriétaire et un groupe sur nobody. Ces fichiers ne seront exploitables que s'ils sont en 777, il faudrait alors mettre le umask en 0777 dans la configuration de nzbget. Je ne sais pas quelle est la bonne méthode a adopter. Moi je choisirai la première étant donné que démarrer et arrêter le SPK ne doit être possible que par le biais de DSM à mon sens. / $ whoami nobody / $ kill 13385 kill: 13385: Operation not permitted

La 0.2 beta arrive bient

En fait DSM 3.1 a foutu un peu le bazar avec /bin/ps si bien que maintenant, si tu lui passes une option qu'il ne connait pas, il t'envoie chier. Ce n'

Oula c'est mauvais

Ok. Ce bug est corrig

J'avoue que je suis a court d'idées. Je n'ai pas l'utilité de cette fonctionnalité pour l'instant donc je n'ai pas regardé. Peut être que j'y jetterai un oeil dans la semaine prochaine. Pour ce qui est du status, il ne peut pas se tromper. Reproduis le problème puis tape en SSH : ps | grep nzbget et affiche moi ici la sortie

Ça me parait bizarre. Tu peux me donner les derniers logs ? /var/log/messages : Les lignes avec uMurmurd dedans /usr/local/umurmur/var/umurmur.log : Les dernières lignes Est-ce que le client Mumble voit le serveur uMurmur ? (avec un ping) Que dit Mumble quand tu essayes de te connecter sur le uMurmur ? Edit: Je viens de tester, tout marche bien chez moi. Il faut accepter le nouveau certificat, peut être que tu l'as rejeté ?