Se connecter à ZimaOS via SSH et constater que les dossiers système sont en lecture seule ne signifie pas que votre compte est défectueux. ZimaOS protège délibérément la majeure partie de son système de fichiers de système d’exploitation contre les écritures ordinaires, même lorsqu’un utilisateur élève ses privilèges. Le fil source de février 2026 a commencé par une question sur les permissions SSH, mais a rapidement révélé un objectif plus utile : récupérer automatiquement les photos d’un téléphone depuis OneDrive vers le stockage NAS, puis rendre ces fichiers disponibles dans Immich.
La leçon importante en matière de conception consiste à séparer la couche système immuable des données accessibles en écriture. Utilisez SSH ou le terminal web pour l’administration, et conservez les scripts, la configuration et les données applicatives créés par l’utilisateur sous /DATA ou un autre emplacement de stockage géré, et évitez d’essayer de transformer ZimaOS en serveur Ubuntu classique en installant des paquets dans le système de fichiers racine protégé.
L’accès SSH en lecture seule est un comportement normal de ZimaOS
L’utilisateur d’origine pouvait s’authentifier avec son nom d’utilisateur et son mot de passe ZimaOS habituels, mais ne pouvait pas écrire là où il s’y attendait ni installer rclone comme si l’hôte était sous Debian ou Ubuntu. Une première réponse suggérait sudo ou sudo -i, mais un autre participant de la communauté a correctement distingué les privilèges de la possibilité d’écriture du système de fichiers : devenir root ne rend pas une image système en lecture seule accessible en écriture.
Les directives actuelles d’IceWhale concernant la CLI confirment désormais directement ce comportement : la plupart des dossiers système sont en lecture seule, même lorsque vous êtes connecté en tant que root, tandis que les données utilisateur et applicatives se trouvent sous /DATA.
Utilisez le modèle actuel du système de fichiers CLI de ZimaOS avant de considérer un échec d’écriture sous /usr, /app ou un autre chemin système comme un problème de permissions.
sudo modifie les privilèges, pas la conception du système de fichiers racine
sudo reste utile lorsqu’une commande nécessite des privilèges élevés, mais il ne peut pas rendre accessible en écriture un système de fichiers que ZimaOS monte intentionnellement en lecture seule. Cela explique pourquoi « essayer avec root » peut être une mauvaise réponse lorsque l’erreur est Système de fichiers en lecture seule plutôt que Permission refusée.
Pour une personnalisation durable, placez les scripts et les données d’état sur un espace de stockage accessible en écriture. Ne créez pas de flux de travail dépendant de la modification manuelle de l’image de base du système d’exploitation, car les mises à jour peuvent remplacer ou invalider ces modifications, même si une solution de contournement fonctionne temporairement.
La version actuelle de ZimaOS active SSH depuis le mode développeur
SSH reste une méthode d’administration prise en charge. La version actuelle de ZimaOS propose une option d’accès SSH sous Paramètres > Mode développeur et fournit également un terminal accessible depuis le navigateur.
Suivez la configuration actuelle de SSH et du terminal web au lieu de supposer que des dossiers système en lecture seule signifient que SSH n’est que partiellement activé.
L’utilisateur source souhaitait le flux OneDrive → NAS → Immich
Le flux de travail souhaité par l’utilisateur était le suivant :
- téléverser un petit lot de photos et de vidéos du téléphone vers l’espace OneDrive gratuit ;
- transférer régulièrement ces fichiers de OneDrive vers le NAS ;
- rendre la destination locale disponible pour Immich ;
- après avoir confirmé le transfert, supprimez les copies cloud afin de pouvoir réutiliser le quota OneDrive limité.
Il s’agit de plus qu’une sauvegarde ordinaire. Cette opération comprend une étape finale destructive : supprimer la source après un transfert réussi.
L’application Backup de février 2026 était décrite comme une solution de copie/synchronisation, et non de déplacement
Dans le fil de discussion source, l’utilisateur a constaté que l’application Backup intégrée copiait les données OneDrive, mais ne vidait pas ensuite le dossier cloud. Une réponse de la communauté a indiqué que ce comportement était intentionnel et a décrit l’application Backup comme non destructive, sans option de suppression après copie dans cette interface.
Cette affirmation correspond à l’environnement source de février 2026. Il s’agissait d’une explication de la communauté, et non d’une réponse du personnel d’IceWhale dans le fil de discussion ; elle ne doit donc pas être figée en une affirmation permanente selon laquelle « ZimaOS ne peut jamais déplacer de fichiers cloud ».
La version actuelle de ZimaOS Files peut déplacer les données cloud vers le stockage local
La documentation actuelle d’IceWhale montre désormais OneDrive, Google Drive et Dropbox montés directement dans Files. Elle explique également comment sélectionner du contenu cloud, choisir un espace de stockage local, lancer un déplacement et vérifier que le transfert est terminé.
Pour une migration occasionnelle ou supervisée manuellement, utilisez le flux de transfert cloud vers stockage local actuellement disponible dans Files. Cette solution est plus simple que de créer un conteneur rclone lorsque le transfert ne nécessite pas de planification sans surveillance.
La sauvegarde et le déplacement ont des sémantiques d’échec différentes
Une sauvegarde doit conserver la source. Un déplacement peut supprimer la source après le transfert. Cette différence est importante lorsque la source constitue l’unique copie cloud des photos du téléphone.
Si l’objectif est de récupérer automatiquement de l’espace OneDrive, l’automatisation ne doit pas supprimer un fichier cloud simplement parce qu’une commande de copie s’est terminée sans erreur manifeste. Un flux de travail plus sûr vérifie que le fichier local existe et est lisible, puis ne supprime la source qu’une fois la condition de réussite explicitement remplie.
Pour l’automatisation planifiée de suppression après transfert, isolez rclone du système d’exploitation hôte
La communauté source recommandait d’exécuter rclone dans Docker plutôt que d’essayer de l’installer dans le système de fichiers racine de ZimaOS. Cette architecture correspond à la conception générale de ZimaOS : le conteneur contient l’outil, tandis que sa configuration et les dossiers de destination sont associés à un stockage ZimaOS accessible en écriture.
Si vous créez ce flux de travail, conservez la configuration et les scripts rclone sur un stockage persistant, par exemple /DATA/AppData ou un autre dossier de données géré. Ne mappez que les répertoires locaux nécessaires à la tâche au lieu d’accorder au conteneur un accès étendu à l’ensemble du NAS.
La commande exacte rclone move La commande était une recommandation de la communauté, et non une commande rédigée par IceWhale dans ce fil ; testez-la donc sur des fichiers jetables avant d’autoriser toute automatisation à supprimer les originaux du cloud.
Gardez, lorsque c’est approprié, le dossier de transfert séparé de la bibliothèque gérée par Immich
L’utilisateur source a indiqué utiliser le répertoire téléchargé comme emplacement d’importation d’Immich. Selon la version et le déploiement, Immich peut utiliser des données de bibliothèque externe ou de type téléversement de différentes manières. Ne dirigez pas simplement une tâche de déplacement destructive vers la base de données interne ou les dossiers de données applicatives d’Immich.
Utilisez un dossier multimédia/importation standard sur le stockage NAS géré, puis configurez le paquet Immich actuel pour lire ce dossier avec la méthode de stockage prise en charge par la version que vous utilisez.
La fonction Backup actuelle a toujours un objectif différent de la migration cloud
La fonction Backup actuelle est conçue autour de copies planifiées et reprenables, ainsi que de points de restauration versionnés entre le cloud, le réseau local, les périphériques USB et le stockage Zima. IceWhale distingue explicitement la synchronisation cloud de la sauvegarde, car une mise en miroir destructive peut propager les erreurs.
Si l’objectif est la protection plutôt que la récupération d’espace, le flux de sauvegarde actuel de ZimaOS convient mieux qu’une automatisation supprimant les fichiers après leur transfert.
Un flux de travail OneDrive pour les photos plus sûr
- Connectez OneDrive via la version actuelle de ZimaOS Files ou un conteneur dédié.
- Choisissez une destination locale inscriptible sur un espace de stockage géré, et non un dossier système.
- Commencez par transférer un petit lot de test.
- Vérifiez localement le nombre et la taille des fichiers, ainsi que quelques photos et vidéos réelles.
- Vérifiez qu’Immich peut voir le contenu local à l’aide de la méthode d’importation prévue.
- Ce n’est qu’ensuite que vous pourrez supprimer les originaux du cloud si votre objectif est de récupérer de l’espace dans votre quota.
- Conservez une sauvegarde indépendante des photos irremplaçables ; déplacer l’unique copie cloud vers un seul NAS ne constitue pas une sauvegarde 3-2-1.
FAQ sur l’accès SSH en lecture seule de ZimaOS
Pourquoi puis-je me connecter à ZimaOS via SSH, mais pas créer de fichiers dans les dossiers système ?
La plupart des dossiers système de ZimaOS sont en lecture seule par conception. Les données utilisateur et applicatives inscriptibles doivent être stockées dans un espace de données géré, tel que /DATA.
La commande sudo rendra-t-elle le système de fichiers racine de ZimaOS inscriptible ?
Non. Des privilèges élevés ne rendent pas inscriptible un système de fichiers intentionnellement monté en lecture seule.
La version actuelle de ZimaOS peut-elle accéder à OneDrive sans installer manuellement rclone ?
Oui. La version actuelle de ZimaOS Files peut se connecter directement à OneDrive et déplacer le contenu cloud sélectionné vers le stockage local.
La suppression automatique après la copie était-elle disponible dans l’interface Backup source ?
Le fil de discussion de la communauté de février 2026 indiquait que cette fonction n’y était pas exposée. Considérez cela comme une limitation historique de l’application Backup, et non comme une affirmation permanente concernant tous les flux actuels de transfert vers le cloud.
