Início / ubuntu / Perguntas / 1522408
Accepted
Will
Asked: 2024-08-04 04:06:35 +0800 CST

Samba Share com vários proprietários no sistema cliente

  • 772

Eu tenho uma grande pasta de dados em um dos meus servidores que, por motivos muito longos, gostaria de migrar para um NAS dedicado (Openmediavault) e depois compartilhar de volta com o servidor existente.

Dentro dele estão arquivos que pertencem a www-data (pasta de dados nextcloud), will (me), media (uma pasta de dados plex) e cctv (um armazenamento de gravação para câmeras), entre alguns outros conteúdos.

Existe uma maneira fácil de manter uma estrutura de propriedade como essa em um armazenamento compartilhado ou seria melhor dividir cada uma das pastas em compartilhamentos separados e montá-las individualmente?

Idealmente, eu gostaria simplesmente de manter os proprietários existentes das pastas e arquivos. Clonei a imagem da unidade para teste, mas apesar de selecionar a configuração "Herdar permissões" que soa correta

The permissions on new files and directories are normally governed by create mask and directory mask but the inherit permissions parameter overrides this. This can be particularly useful on systems with many users to allow a single share to be used flexibly by each user.

Mas ao montar a unidade no servidor (clonado para teste) através de uma entrada fstab

//10.10.10.65/willzpool /willzpool cifs credentials=/root/smbcredentials 0 0

tudo dentro do compartilhamento pertence ao root. Mesmo como root, não consigo fazer nada dentro do compartilhamento.

Estou faltando alguma coisa ou meu objetivo é impossível?

permissions

1 respostas

  1. Best Answer

    Ok, então consegui resolver isso de duas maneiras.

    Com o Samba, mesmo que o usuário do samba tenha acesso ao compartilhamento, ele ainda precisará de permissões do sistema de arquivos para os arquivos incluídos.

    Então, para atingir meu objetivo, eu precisaria usar vários usuários do samba, cada um com diferentes direitos de acesso ao sistema de arquivos (incluindo um que teria acesso às pastas de propriedade de www-data, o que não parecia uma boa ideia) OU Eu poderia compartilhar toda a pasta de dados com um usuário, compartilhar cada pasta separadamente e lidar com a propriedade do arquivo no cliente. Foi o que fiz e funcionou. Chorei tudo no diretório de dados como usuário com acesso samba e no cliente fstab fiz isso

    //10.10.10.65/cctv /willzpool/cctv cifs credentials=/root/smbcredentials,uid=1010,gid=1010 0 0
//10.10.10.65/media /willzpool/media cifs credentials=/root/smbcredentials,uid=1000,gid=1003 0 0
//10.10.10.65/nextcloud /willzpool/nextcloud cifs credentials=/root/smbcredentials,uid=33,gid=33,file_mode=0770,dir_mode=0770 0 0
//10.10.10.65/virtshare /willzpool/virtshare cifs credentials=/root/smbcredentials,uid=1004,gid=1003 0 0
//10.10.10.65/will /willzpool/will cifs credentials=/root/smbcredentials,uid=1000,gid=1000 0 0

    Isso deu a cada pasta a propriedade e as permissões corretas no cliente e tudo funcionou, mas fiquei desconfortável com o fato de as propriedades no servidor NAS terem que ser alteradas. Eu queria manter a capacidade de desconectar a unidade do OMV e reconectá-la ao servidor Ubuntu, se necessário, e usá-la diretamente, então queria manter as mesmas propriedades e permissões na pasta real.

    O NFS deu um pouco mais de trabalho, tive que criar usuários e grupos no servidor que correspondessem ao cliente. A exportação foi bem simples

    export/willzpool 10.10.10.62(fsid=xxxx,rw,no_subtree_check,secure,no_root_squash) 10.10.10.68(fsid=xxxx,rw,no_subtree_check,secure,no_root_squash)

    no_root_squash provavelmente não é recomendado, mas eu queria manter a capacidade de controlar a propriedade de arquivos no cliente, alterando arquivos e pastas, se necessário.

    No cliente, configurei uma nova entrada fstab

    10.10.10.65:/export/willzpool /willzpool nfs defaults  0 0

    Infelizmente, isso não conseguiu montar o compartilhamento por algum motivo. Suspeito que ele estava tentando montá-lo antes da rede estar ativa. Tentei adicionar _netdev à entrada fstab, mas não fez diferença. Suponho que poderia ter descoberto, mas acabei de configurar um cronjob para ser executado na inicialização

    mount -a

    que resolveu o problema.

    Tive que mexer um pouco no compartilhamento de gravação da minha câmera, que compartilhei como NFS do novo servidor OMV, mas acabou sendo um problema de firewall, pois o OMV estava usando uma porta diferente do servidor Ubuntu (minhas câmeras estão em um vlan sem acesso a qualquer outra coisa além das portas que eu permito especificamente, mas todo o resto foi bastante simples.

    No geral, sinto que o NFS deu mais trabalho, mas estou mais feliz com o resultado final porque a propriedade/permissões são consistentes entre cliente/servidor. Também PARECE que é um pouco mais rápido, mas não o comparei.

    EDITAR

    Encontrei uma maneira ainda melhor de montar o compartilhamento - autofs

    Isso é executado como um serviço e cria um diretório “fantasma” no sistema de arquivos principal. Assim que algo tenta acessar o diretório, ele (com uma rapidez impressionante) monta o compartilhamento. Isso também significa que se o compartilhamento conseguir ser desmontado por qualquer motivo, ele deverá voltar a funcionar, pois Nextcloud e Deluge estão sempre lendo o conteúdo do diretório

    • 1

relate perguntas