Iniciar sessão no ZimaOS por SSH e descobrir que as pastas do sistema são só de leitura não significa que a sua conta esteja danificada. O ZimaOS protege deliberadamente a maior parte do sistema de ficheiros do sistema operativo contra escritas normais, mesmo quando um utilizador eleva os privilégios. O tópico original, de fevereiro de 2026, começou como uma questão sobre permissões SSH, mas rapidamente revelou um objetivo mais útil: transferir automaticamente fotografias do telemóvel do OneDrive para o armazenamento NAS e, em seguida, disponibilizar esses ficheiros ao Immich.
A lição importante de conceção é separar a camada imutável do sistema dos dados com permissões de escrita. Utilize o SSH ou o terminal Web para administração e mantenha os scripts, a configuração e os dados das aplicações criados pelo utilizador em /DATA ou outra localização de armazenamento gerida, e evite tentar transformar o ZimaOS num servidor Ubuntu convencional instalando pacotes no sistema de ficheiros raiz protegido.
O acesso SSH só de leitura é um comportamento normal do ZimaOS
O utilizador original conseguia autenticar-se com o nome de utilizador e a palavra-passe normais do ZimaOS, mas não conseguia escrever no local esperado nem instalar o rclone como se o anfitrião fosse Debian ou Ubuntu. Uma primeira resposta sugeriu sudo ou sudo -i, mas outro participante da comunidade distinguiu corretamente os privilégios da mutabilidade do sistema de ficheiros: tornar-se root não torna editável uma imagem do sistema só de leitura.
As orientações atuais da CLI da IceWhale confirmam diretamente este comportamento: a maioria das pastas do sistema é só de leitura, mesmo quando a sessão é iniciada como root, enquanto os dados de utilizador e das aplicações ficam em /DATA.
Consulte o modelo atual do sistema de ficheiros CLI do ZimaOS antes de interpretar uma escrita falhada em /usr, /app ou noutro caminho do sistema como um problema de permissões.
O sudo altera os privilégios, não o desenho do sistema de ficheiros raiz
O sudo continua a ser útil quando um comando requer privilégios elevados, mas não pode contornar um sistema de ficheiros que o ZimaOS monta intencionalmente como só de leitura. Isto explica por que razão «tentar como root» pode ser a resposta errada quando o erro é Sistema de ficheiros só de leitura, e não Acesso negado.
Para uma personalização duradoura, coloque os scripts e o estado num armazenamento com permissões de escrita. Não crie um fluxo de trabalho que dependa da modificação manual da imagem base do sistema operativo, pois as atualizações podem substituir ou invalidar essas alterações, mesmo que uma solução alternativa funcione temporariamente.
O ZimaOS atual ativa o SSH a partir do Modo de programador
O próprio SSH continua a ser uma via de administração suportada. O ZimaOS atual disponibiliza um botão de acesso SSH em Definições > Modo de programador e também fornece um terminal no navegador.
Siga a configuração atual do SSH e do terminal Web, em vez de assumir que as pastas do sistema só de leitura significam que o SSH está apenas parcialmente ativado.
O utilizador de origem pretendia OneDrive → NAS → Immich
O fluxo de trabalho pretendido pelo utilizador era:
- carregar um pequeno lote de fotografias e vídeos do telemóvel para o espaço gratuito do OneDrive;
- transferir regularmente esses ficheiros do OneDrive para o NAS;
- disponibilizar o destino local para o Immich;
- depois de confirmar a transferência, remova as cópias na nuvem para que a quota limitada do OneDrive possa ser reutilizada.
Isto é mais do que uma cópia de segurança normal. Inclui um passo final destrutivo: eliminar a origem após uma transferência bem-sucedida.
A aplicação de cópia de segurança de fevereiro de 2026 foi descrita como cópia/sincronização, não como transferência
No tópico de origem, o utilizador reparou que a aplicação de cópia de segurança integrada copiava os dados do OneDrive, mas não esvaziava a pasta na nuvem posteriormente. Uma resposta da comunidade indicou que isso era intencional e descreveu a aplicação de cópia de segurança como não destrutiva, sem uma opção de eliminação após a cópia nessa interface.
Essa afirmação pertence ao ambiente de origem de fevereiro de 2026. Tratou-se de uma explicação da comunidade, não de uma resposta de um funcionário da IceWhale no tópico, pelo que não deve ser transformada numa afirmação permanente de que “o ZimaOS nunca pode transferir ficheiros da nuvem”.
Os Ficheiros atuais do ZimaOS podem transferir dados da nuvem para o armazenamento local
A documentação atual da IceWhale mostra agora o OneDrive, o Google Drive e o Dropbox montados diretamente em Ficheiros. Também documenta a seleção de conteúdo na nuvem, a escolha de um espaço de armazenamento local, o início de uma transferência e a verificação da conclusão da transferência.
Para uma migração ocasional ou supervisionada manualmente, utilize o fluxo de transferência atual da nuvem para o armazenamento local em Ficheiros. É mais simples do que criar um contentor rclone quando a transferência não precisa de agendamento autónomo.
A cópia de segurança e a transferência têm semânticas de falha diferentes
Uma cópia de segurança deve preservar a origem. Uma operação de transferência pode remover a origem após a transferência. Essa diferença é importante quando a origem é a única cópia na nuvem das fotografias do telemóvel.
Se o objetivo for libertar espaço no OneDrive automaticamente, a automatização não deve eliminar um ficheiro na nuvem apenas porque um comando de cópia terminou sem um erro evidente. Um fluxo de trabalho mais seguro verifica se o ficheiro local existe e pode ser lido, eliminando depois a origem apenas quando a condição de sucesso estiver definida de forma explícita.
Para a automatização agendada de eliminação após a transferência, isole o rclone do sistema operativo anfitrião
A comunidade de origem recomendou executar o rclone no Docker, em vez de tentar instalá-lo no sistema de ficheiros raiz do ZimaOS. Essa arquitetura corresponde ao design mais amplo do ZimaOS: o contentor contém a ferramenta, enquanto a respetiva configuração e as pastas de destino são mapeadas para armazenamento gravável do ZimaOS.
Se criar esse fluxo de trabalho, mantenha a configuração e os scripts do rclone num armazenamento persistente, como /DATA/AppData ou outra pasta de dados gerida. Mapeie apenas os diretórios locais de que a tarefa necessita, em vez de conceder ao contentor acesso amplo a todo o NAS.
O rclone move o comando foi uma recomendação da comunidade, não um comando criado pela IceWhale neste tópico; por isso, teste-o em ficheiros descartáveis antes de permitir que qualquer automatização elimine os originais da nuvem.
Mantenha a pasta de transferência separada da biblioteca gerida pelo Immich, quando apropriado
O utilizador de origem descreveu a utilização do diretório transferido como localização de importação do Immich. O Immich pode consumir dados de uma biblioteca externa ou dados ao estilo de carregamento de formas diferentes, consoante a versão e a implementação. Não aponte simplesmente uma tarefa de movimentação destrutiva para a base de dados interna ou para as pastas de dados da aplicação do Immich.
Utilize uma pasta normal de multimédia/importação no armazenamento NAS gerido e, em seguida, configure o pacote Immich atual para ler essa pasta utilizando o método de armazenamento suportado pela versão que estiver a executar.
A Cópia de Segurança atual tem ainda uma finalidade diferente da migração a partir da nuvem
A Cópia de Segurança atual do ZimaOS foi concebida para cópias agendadas e retomáveis, bem como para pontos de restauro com versões, entre a Cloud, a LAN, USB e o armazenamento Zima. A IceWhale distingue explicitamente a sincronização na nuvem da cópia de segurança, porque a replicação destrutiva pode propagar erros.
Se o objetivo for a proteção e não a recuperação de quota, o fluxo de trabalho atual de cópia de segurança do ZimaOS é mais adequado do que a automatização da eliminação após a transferência.
Um fluxo de trabalho mais seguro para fotografias no OneDrive
- Ligue o OneDrive através do ZimaOS Files atual ou de um contentor dedicado.
- Escolha um destino local gravável no armazenamento gerido, não uma pasta do sistema.
- Transfira primeiro um pequeno lote de teste.
- Verifique as contagens e os tamanhos dos ficheiros, bem como algumas fotografias/vídeos reais localmente.
- Confirme que o Immich consegue ver os conteúdos locais utilizando o método de importação pretendido.
- Só depois remova os originais da nuvem, se o objetivo for libertar quota.
- Mantenha uma cópia de segurança independente das fotografias insubstituíveis; mover a única cópia na nuvem para um único NAS não constitui uma cópia de segurança 3-2-1.
Perguntas frequentes sobre o acesso SSH só de leitura do ZimaOS
Porque consigo ligar-me ao ZimaOS por SSH, mas não consigo criar ficheiros nas pastas do sistema?
A maioria das pastas do sistema ZimaOS é só de leitura por conceção. Os dados graváveis dos utilizadores e das aplicações devem ficar num armazenamento de dados gerido, como /DATA.
O sudo tornará o sistema de ficheiros raiz do ZimaOS gravável?
Não. Os privilégios elevados não alteram um sistema de ficheiros que está intencionalmente montado como só de leitura.
O ZimaOS atual consegue aceder ao OneDrive sem instalar manualmente o rclone?
Sim. O ZimaOS Files atual pode ligar-se diretamente ao OneDrive e mover conteúdos selecionados da nuvem para o armazenamento local.
A eliminação automática após a cópia estava disponível na interface de cópia de segurança de origem?
O tópico da comunidade de fevereiro de 2026 indicava que isso não estava exposto nessa área. Considere-o uma limitação histórica da aplicação de cópia de segurança, não uma afirmação permanente sobre todos os fluxos atuais de transferência a partir da nuvem.
