CoolRaoul

Bof, une appli qui part en vrille sera toujours capable de finir par remplir /tmp, quelque soit sa taille.

On parle toujours de "/tmp" là?

Je reconnais que cela ne donne pas beaucoup d'informations pour prendre une décision Le 213+ sera quand meme plus réactif niveau CPU, la question a te poser est si tu as vraiment besoin des 4 baies je pense. Le 213+, avec une config 2 disques non RAID, le 2eme volume pour les backups du premier (et d'eventuels clients PC) devrait répondre mieux a tes specs je pense.

Sans rien faire, alors que "/tmp/indexdb" était là depuis le 28 février? Ça tient du miracle absolu Dans quel but? Tu es jaloux de Pluton qui en a un plus gros, c'est ça? L'important c'est pas la taille tu sais, hein...

Comparatif non mais la comparaison reste possible:http://www.synology.com/products/compare_spec.php?lang=fre&product_id_list=111,109#compare_show_top

Que veux-tu dire par ça?

Non, c'est pareil pour moi, meme taille, jamais eu de probleme de ce coté. Bigre, tu n'y vas pas de main morte pour un simple /tmp plein!

Utiliser le compte "root" (meme mot de passe qu'admin)

Tu aurais gagné du temps en commençant par le "rm -r" (ce qui aurait probablement rendu la reinstall inutile)

J'ai bien l'impression qu'il n'y a pas eu de formatage de la partition système.

J'ai ajouté une piste de solution à mon message entre temps

Bon, reste a trouver quelle application tu as pu installer qui créé ce volumineux répertoire "indexdb" **EDIT** Tous ces fichiers datent du meme moment le 28 février dernier, une merde a du se passer a ce moment la Je te conseille de faire un "rm -r /tmp/indexdb" suivi d'un reboot

Une recherche sur le forum t'aurait permis de trouver ceci:

Pour info, mon /tmp fait la même taille (59140 Kb) Si il est plein, faut commencer par aller voir ce qui le remplit non? Je commencerai par quelque chose du genre de: find /tmp -size +10k | xargs ls -ldh

Ma pierre à l'édifice:

A ta place je tenterai le reset

Ici, en disant "sous Windows" je parlais d'un environnement 100% Windows (machine stand alone ou client *et* serveur windows) Dans ce contexte les sous dossiers des disques locaux (et réseau entre machines Windows également) sont visibles également si on est connecté via un compte qui n'a pas droit à en visualiser le contenu. (et Linux même combat d'ailleurs). Personne n'imagine qu'ils n'y *arrivent pas*, ils n'ont pas choisi d'implémenter cette option dans DS File voila tout. Pour bien clarifier: Il se trouve que Samba, sur lequel s'appuie le partage de fichier de SDM, dispose de cette option ("hide unreadable = yes" dans smb.conf). Synology a choisi de rendre cette option disponible via son interface de configuration. Cela ne justifie pas de leur reprocher de n'avoir pas implémenté une option équivalente dans tous les autres outils DSM d’accès aux fichiers, alors que même Microsoft ne l'a pas implémenté sur ses OS clients et serveurs. NB: il existe une rubrique du forum dédié spécifiquement au remarques et demandes (http://www.nas-forum.com/forum/forum/136-vos-commentaires-et-suggestions/) Voici sa description: Je ne peux que t'inviter à y poster tes demandes d'évolutions.

Quel est l’intérêt par rapport au de Diaoul ?

Je suppose qu'il faut désactiver le samba natif du syno ? ***EDIT*** Pour quelle raison faut installer gdb et git sur la "partition" debian ?

On ne parle pas de la même chose, dans le cas de DS File il s'agit de la visibilité des *partages*, dans le cas du partage de fichiers Windows il s'agit des *sous-dossiers et fichiers* ça me semble clair: "l'utilisateur ne pourra pas voir les dossiers ou les fichiers dans le dossier partagé. " "dans le dossier": il ne s'agit pas du dossier partagé lui même mais des objets qu'il contient. Et donc, effectivement cette option ne s'applique *pas* à DSFile, les dossiers et sous dossiers sans autorisation y restent visibles. Paut-être, mais il se trouve c'est le cas nativement ni sous Windows ni sous Unix (sans doute aussi sous MacOs mais je ne connais pas), donc on ne peut pas reprocher a Synology de ne pas faire mieux que les OS les plus utilisés dans le monde. En effet, une fausse manip m'avais fait dire ça il y quelques jours. Je confirme, qu'en effet, l'option "Masquer les dossiers et les fichiers des utilisateurs sans autorisations" fonctionne bien *exactement* comme l'indique la doc, a savoir: uniquement "via le protocole de partage de fichiers de Windows" et pour "les dossiers ou les fichiers dans le dossier partagé"

+1000 pour l'utilisations de groupes. Ça pourrait (quoi que) sembler superflu au début mais on se rendra très rapidement compte de l'intéret. Des que l'on va ajouter de nouveaux utilisateurs, suffira de les mettre dans les groupes ad hoc pour qu'ils aient automatiquement les bons accès.

Ou est la contradiction?La doc n'a jamais dit que les dossiers sans acces pour l'utilisateur devraient être visible sous DS File que je sache. **EDIT** Et ce que tu demandes (rendre invisible les dossiers cachés), à ma connaissance aucun système d'exploitation ne le propose. DSM a juste ajouté cette possibilité dans certains cas (sous dossiers via SMB, partage dans filestation, ftp et sans doute d'autres).

Un exemple pas a pas de ce que tu avances stp?

J'ai pensé à ça aussi mais il nous dit avoir fait le test avec différents PC Windows. Serait étonnant qu'il y ait la même erreur de config du firewall windows sur chacun d'eux.

Soyons précis: étant donné que sur mon Syno (avec le même serveur ftp donc) je n'ai pas ce comportement, le problème ne peut pas venir du ftp du syno, mais de quelque chose qui fait filtre entre ton syno et les PC. Etant donné que tu as le même symptôme avec un autre PC, je continue à pencher sur un histoire de firewal (ou peut être de NAT, mais dans un même LAN ça m'étonnerait d'autant plus que, j'imagine, si il y avait un routeur *entre* ton PC et le NAS, tu nous l'aurais dit plutôt que de nous laisser patauger). Essaie déjà de désactiver (temporairement) le firewall du syno. Vérifie aussi que le nom "nas" soit bien résolu avec l'ip *interne* de ton syno Peux-tu confirmer que le message d'erreur est identique en mode passif et en mode actif (ça me surprend beaucoup ça) Explications: Ta copie d'écran montre un test effectué en mode actif. Dans ce mode c'est le NAS qui tente de se connecter au PC pour le flux "data" (en sens inverse). Le timeout indique que cette connexion échoue, donc il y a quelque chose qui ne laisse pas passer la demande de connexion du NAS vers le PC.