En résumé : le chemin interne d’une application n’est pas le même que celui que vous voyez dans les fichiers de ZimaOS
MeTube peut enregistrer les fichiers dans un chemin tel que /downloads à l’intérieur de son conteneur, tandis que ZimaOS associe ce chemin à un dossier complètement différent sur l’hôte. C’est pourquoi les fichiers téléchargés semblent disparaître lorsque vous modifiez le mauvais côté de l’association.
Lisez l’association des volumes comme Chemin de l’hôte → Chemin du conteneur
/media/Storage/Downloads/MeTube -> /downloadsMeTube écrit dans /downloads. Le fichier réel apparaît sous /media/Storage/Downloads/MeTube dans ZimaOS. La page actuelle sur les chemins des applications ZimaOS explique précisément ce modèle.
Docker appelle ce même mécanisme les montages bind de Docker. La page consacrée aux volumes Docker présente l’autre modèle de stockage courant.
Trouvez le fichier en vérifiant d’abord les paramètres de l’application
Ouvrez les paramètres de l’application et examinez chaque ligne de volume. Identifiez le chemin du conteneur utilisé par l’application pour les téléchargements, puis suivez le côté hôte de cette ligne dans les fichiers de ZimaOS. Ne recherchez pas dans l’ensemble du NAS avant d’avoir vérifié l’association.
Conservez les données téléchargées hors du disque système
Pour les applications de téléchargement, les serveurs multimédias et les applications photo, associez les données volumineuses à un véritable espace de stockage plutôt qu’au disque système de ZimaOS. La page sur la migration des données ZimaOS est utile lorsqu’une application écrit déjà sur le mauvais disque.
Utilisez une structure de chemins cohérente entre les applications
Par exemple, attribuez si possible aux applications de téléchargement et aux gestionnaires multimédias le même chemin hôte parent. Cela réduit la confusion liée aux chemins et facilite les sauvegardes. La page sur les exigences des applications ZimaOS fournit davantage de contexte sur le stockage des applications.
