Inodes insuffisants

Bonsoir à tous,

J’ai un soucis que je pense être sur le point de résoudre. Toutefois avant, d’appliquer le “remède” final, j’aurais aimé avoir votre avis et, surtout partager avec vous le fruit de mes recherches car je pense que ça pourrait être utile à d’autres.

Tout a commencé, il y a quelques jours, avec des problèmes de connexion à mon serveur. Au début, il m’était impossible de faire les mises à jour, puis de recevoir mes mails. Je me suis aperçu que ma partition /var était bien remplie en faisant df -h. J’ai essayé de redémarrer mon serveur et là impossible de me connecter en SSH. J’ai sorti le disque dur du serveur et l’ai mis dans mon ordinateur afin de faire de la place. Vu que je n’arrivais pas à recevoir mes mails, je me suis dit que c’était sans doute /var/mail qui était plein. En effet, le dossier était lourd. J’ai donc déplacé le sous-dossier <mon nom d’utilisateur> puis j’ai relancé mon serveur, sur lequel j’ai pu me reconnecter en SSH, envoyer et recevoir des mails, etc… J’étais tout fier de moi mais ça n’a pas duré.

Il m’est de nouveau impossible de faire les mises à jours et de synchroniser les fichiers de ma bibliothèque Zotero (je suppose que le problème vient du serveur WEBDAVS). Par contre, je peux me connecter en WEBDAVS par Nautilus… Je ne suis pas sur du rapport (par contre je suis sur de ma configuration Zotero puisque ça marchait auparavant et que le test proposé par Zotero aboutit, ce n’est qu’à la synchronisation que ça plante).

Pour illustration, sudo apt-get upgrade donne le résultat suivant :
“Lecture des listes de paquets… Erreur !
E: Impossible d’ouvrir le fichier /var/cache/apt/pkgcache.bin - open (28: Aucun espace disponible sur le périphérique)
E: Échec de la troncature du fichier - ftruncate (9: Mauvais descripteur de fichier)
E: Les listes de paquets ou le fichier « status » ne peuvent être analysés ou lus.”

Et là, je m’aperçois en faisant df -i (pour afficher les inodes libres et ceux utilisés) que /var n’a plus aucun inode de libre… Je me dis qu’il doit y avoir quelque chose qui me créer des petits fichiers à tour de bras. Je cherche en utilisant “Analyseur d’utilisation des disques” sous Debian (programme avec interface graphique supportant l’analyse de disques distants via différents protocoles, notamment SSH). Je trouve alors pas moins de 143 738 (sur 178 927 pour l’intégralité de /var) pour seulement 55,9 MO (sur 888,4 MO pour l’intégralité de /var) dans /var/www/owncloud/lib/private/session. J’imagine très fortement que mon soucis vient de là. Il me semble que ça tombe sous le sens que ce dossier joue un rôle dans les sessions Owncloud et vu le nombre de fichiers j’imagine qu’un nouveau fichier est crée (puis conservé) par session et que cela est généré par de nombreuses connexions WEBDAVS…

Est-ce que je peux supprimer tous ou certains de ces fichiers sans crainte ?

Merci de votre aide. J’espère que ce début de résultat pourra être utile à d’autres.

Bonne soirée,

Oui tu peux.

Ça ressemble à une attaque contre ton OwnCloud ceci dit, merci du report !

Merci de ta réponse !

Dans session/, il n’y a que des fichiers de session à l’exception de deux autres fichiers : internal.php et memory.php (edit : et session.php). J’imagine qu’il faut les garder eux.

Je t’avoue que je n’avais pas forcément pensé à une attaque mais plutôt à des erreurs de connexion (du genre un périphérique mal paramétré qui tenterait de se connecter en vain). Puis je me suis dit que si c’était un problème commun lié à l’accumulation de fichiers de sessions, d’autres utilisateurs seraient aussi affectés, tout du moins ceux ayant à peu près résintallé Yunohost, comme je l’ai fait, pour passer à la V2 dès sa sortie. Alors, je me suis dit que ça devait être lié à une spécificité de mon installation mais comme je n’ai pas changé grand chose, je ne comprenais pas. J’ai regardé le contenu des fichiers de session (quelques échantillons), il contient bien mon compte utilisateur et le mot de passe associé (d’ailleurs c’est normal qu’il apparaisse en clair ?). En réfléchissant un peu, j’ai trouvé une hypothèse : ce nombre incroyable de connexions pourrait provenir du montage que j’avais décrit ici. Si ce n’est pas le comble, saturer son disque, en voulant augmenter sa capacité de stockage…

Ah, c’est bien possible en effet ^^