Estou executando o Windows 10 e o Fedora Linux 40 KDE Plasma no mesmo sistema. Cada SO está instalado em uma unidade física diferente. Também tenho uma unidade SSD adicional montada no sistema, que é montada automaticamente em ambos os SOs, ambos com acesso de leitura e gravação à dita terceira unidade (doravante "unidade compartilhada").
A ideia de usar o sistema dual-boot é usar principalmente o Linux para quase tudo e pular para o Windows sempre que necessário (para coisas como, mas não se limitando a, executar alguns aplicativos GUI exclusivos do Windows).
A unidade compartilhada é uma btrfsunidade de sistema de arquivos. Sua entrada de ponto de montagem /etc/fstabé a seguinte:
UUID=MY_BTRFS_UUID /MY_MOUNTPOINT btrfs nofail,defaults,compress-force=zstd:3,noatime,lazytime,commit=120,space_cache=v2,nofail 0 0
Notei o seguinte comportamento:
Estou trabalhando no Linux em um arquivo específico salvo no meu drive compartilhado usando um aplicativo GUI (eu estava trabalhando em um arquivo .blend usando o Blender). O arquivo foi criado originalmente no meu sistema Linux (portanto atribuído a uma conta de usuário). Quando eu inicializo no Windows, eu posso editar o arquivo criado no Linux muito bem e salvar as alterações no drive compartilhado. Inicializando novamente no Linux, eu posso abrir (ler, eu acho) através do aplicativo GUI, mas -de lá- eu não posso mais salvar (escrever nele). Na verdade, eu apenas tentei recriar o mesmo comportamento usando um arquivo de texto simples. Eu o criei no Windows e de volta no Linux eu não consigo salvar as alterações usando um editor de texto simples (como o Kate).
A partir de uma simples inspeção e do meu conhecimento básico, parece que o problema decorre do fato de que os arquivos criados/sobrescritos no Windows são atribuídos a "nobody:users" (acredito que seja lido como "user:group"). Seja editável no Linux ou não, usar ls -lh em um determinado diretório informa que todos os arquivos compartilham as mesmas permissões, apenas uma combinação diferente de usuário:grupo. Os arquivos editáveis são atribuídos à forma avaliada de $USER:$USER (não me lembro de especificar explicitamente o mesmo nome de usuário e grupo, mas ei, talvez eu tenha feito isso, eu apenas sigo o fluxo durante a configuração). Uma cópia de um arquivo "nobody" (feito por meio de simples copiar e colar na interface GUI do Dolphin) é reatribuída ao usuário Linux atual, tornando o arquivo editável. A tentativa de salvar o arquivo de texto fictício original (criado no Windows) usando Kate solicita uma senha e, quando fornecida, as alterações são de fato gravadas, mas a propriedade permanece a mesma ("nobody"). Como era de se esperar, tentar editar o mesmo arquivo novamente exigirá privilégios de root mais uma vez.
Outra coisa que vale a pena mencionar é que, enquanto alguns aplicativos GUI fornecem a opção de elevar privilégios (como Kate, como mencionei acima), outros aplicativos GUI (como o Blender, no meu caso) não parecem fornecer nenhuma opção para superar isso. O Blender apenas retorna " (caminho) não é gravável ". Eu poderia ter vivido (embora não feliz) com a necessidade de fornecer uma senha sempre que necessário, mas esse não é o caso e preciso encontrar uma solução alternativa. Obviamente, eu preferiria não ter que reatribuir manualmente as propriedades a cada vez.
Agora, sou uma pessoa simples, quero poder fazer login em cada SO e trabalhar em arquivos/diretórios compartilhados perfeitamente. Qual seria a melhor abordagem para lidar com isso? Não acho que eu deva me importar particularmente com o status de propriedade, a menos que, é claro, isso traga coisas das quais eu (muito possivelmente) não tenha conhecimento.