Como permitir que os usuários colaborem editando arquivos em um diretório compartilhado

Question

Eu tenho o que acho ser um caso de uso muito normal e muito típico. Estou surpreso, parece (até agora) que não há uma solução. Eu suponho que estou negligenciando algo óbvio. Muitas pessoas precisam de uma solução para esse caso de uso.

Até cinco usuários diferentes no mesmo grupo têm contas de login em um computador. Eles nem todos fazem login ao mesmo tempo.

Atualização 1: os documentos são arquivos de texto e planilhas que residem em nosso servidor local. Não queremos hospedar documentos no Google ou em qualquer servidor externo.

Nós não precisamos de colaboração em tempo real.

Esses usuários da "equipe" do grupo precisam colaborar lendo e gravando os arquivos em um diretório compartilhado. O diretório que contém esses arquivos reside em um servidor local. O diretório compartilhado pode ser montado no cliente pelos métodos padrão do Linux. Poderíamos usar ACLs, se necessário, porque o BTRFS tem suporte integrado.

Todos os usuários podem efetuar login no servidor via SSH usando as chaves. O usuário e o ID do grupo são os mesmos no cliente e no servidor. Nenhum dos usuários tem permissões sudo ou outras permissões especiais. Tudo o que eles têm em comum é ser membro do grupo "equipe".

O diretório compartilhado não está no diretório inicial de qualquer usuário. É de propriedade do mesmo grupo "equipe" com permissões rwx e seu caminho é totalmente acessível a todos os usuários em "equipe". Podemos alterar as permissões conforme necessário, mas nenhum usuário fora do grupo "equipe" poderá ler ou gravar arquivos nesse diretório.

O cliente e o servidor executam o Arch Linux e ambos também executam o BTRFS.

Nós testamos o NFS por cerca de dez anos e tivemos muitas permissões / problemas de acesso. Um dos nossos principais problemas de suporte foi resolver problemas de permissão para os usuários. Decidimos mudar do NFS porque nunca encontramos uma boa solução para os problemas de permissões.

Mudamos para o SSHFS porque "poderíamos usar apenas as permissões normais do sistema de arquivos". Até agora, não conseguimos atingir nosso objetivo simples declarado acima com o SSHFS. Consulte aqui e here .

Não ouvimos muitas coisas boas sobre o Samba, então nunca tentamos. O que mais há?

Este parece ser um caso de uso tão comum. Como isso normalmente seria resolvido?

Nem sequer temos um caso complexo. Por exemplo, todas as máquinas (servidores e clientes) em nossa rede executam o Linux. E todas as máquinas estão em uma LAN local. É simples. Mas eu não encontrei uma solução que funcione.

    

Answer 1

Na verdade, é bastante fácil. A maioria das pessoas parece achar que precisam definir permissões de todos os arquivos em um determinado diretório, mas isso não é verdade. Apenas o diretório de nível superior fará:

chown :team /path/to/dir
chmod 2770 /path/to/dir

Primeiro, definimos o proprietário do grupo para o grupo team , que você diz já existir e contém as pessoas que devem poder acessar o diretório correto. Em seguida, definimos as permissões para "definir o ID do grupo" no diretório (para que todos os arquivos criados abaixo desse diretório também pertençam ao team group; não são estritamente necessários, mas acho que é um lembrete útil), e conceda permissões completas a qualquer pessoa no grupo team , bem como ao proprietário do diretório. Qualquer pessoa não nesse grupo terá others permissão, que está vazia aqui.

O resultado dessa configuração será que, para qualquer pessoa que não esteja no grupo team , mesmo fazendo um ls nesse diretório, obterá Permission denied . As pessoas que são um membro do grupo correto, no entanto, poderão ler e escrever nesse diretório, desde que nenhum arquivo seja definido individualmente para permissões de arquivo erradas. Se nenhum desses arquivos deve ser protegido contra a escrita, corrija as permissões agora:

chmod -R g+rw /path/to/dir
find /path/to/dir -type d -print0 | xargs -0 chmod g+x

Na ausência de ACLs, definir as permissões para arquivos futuros (ou seja, recém-criados) não é algo que você possa fazer definindo criativamente os bits de permissão; os usuários precisam definir sua umask. Você pode fazer isso por meio de uma linha em /etc/profile :

umask 002

É importante definir isso, porque o padrão em muitas distribuições será 022 (permitindo ler, mas não gravar, permissões para membros do grupo), 077 (permitindo nada para outros usuários), ou 027 (permitindo ler, mas não escrever, agrupar; e nada para os outros). Nenhuma dessas opções é o que você quer.

Se você tiver requisitos diferentes para partes diferentes de seu sistema de arquivos, ou se quiser garantir que as pessoas não atrapalhem as coisas brincando com sua umask individualmente, use as ACLs padrão:

find /path/to/dir -type d -print0 | xargs -0 setfacl -m d:g:team:rwx -m d:o:---

Depois de configurar tudo, realmente não importa se você usa SSHFS ou NFS. Se ainda assim não funcionar, provavelmente é melhor voltar com perguntas mais específicas

    

Answer 2

Dependendo do documento, use um sistema de controle de versão como git com um repositório acessível a todos (bom para colaborar em software) ou use algo como o Google Docs que permita a edição colaborativa de texto arquivos (bom para colaborar, por exemplo, em relatórios). Estas são as soluções em uso no meu local de trabalho atual.

Veja também a entrada da Wikipedia no editor colaborativo em tempo real .

IMHO, a edição simultânea de documentos em uma unidade compartilhada é problemática, pois os documentos salvos por um usuário substituiriam facilmente as alterações feitas por outro usuário. Também não há como rastrear quem fez as alterações ou reverter alterações nas versões anteriores do documento.