Migrando montagens com permissões idênticas não funcionando

1

Eu tenho duas montagens /mount1 e /mount2 . Eu corri o comando:

rsync -azrt /mount1/* /mount2/

para clonar tudo, de /mount1 a /mount2 .

Em seguida, alterei o /etc/fstab (veja abaixo) para remover /mount1 e montar /mount2 para /mount1 , mas as coisas (incluindo minhas pastas de usuários locais dos servidores de e-mail) não estão funcionando corretamente por motivos de permissão mais, mesmo quando comparando as permissões com as montagens antes e depois de serem idênticas!!

/etc/fstab antes (funcionando):

UUID="3999A4F22570EAC4" /mount2   ntfs-3g nobootwait,permissions,locale=en_US.utf8    0   2
mhddfs#/mount3,/mount4 /mount1 fuse defaults,allow_other,nobootwait,nonempty,uid=1000,gid=1000,umask=007 0 0

/etc/fstab depois (não está funcionando):

UUID="3999A4F22570EAC4" /mount1   ntfs-3g nobootwait,permissions,locale=en_US.utf8    0   2

Em que UUID="3999A4F22570EAC4" é /mount2 que tem o conteúdo do anterior /mount1

    
por maxisme 02.05.2016 / 19:28

1 resposta

1

Opções genéricas do FUSE

1) Eu observei que allow_other não foi definido na montagem do sistema de arquivos ntfs-3g . O padrão para o FUSE não é permitir o acesso de outros usuários. mhddfs é um sistema de arquivos FUSE e, portanto, é ntfs-3g (mas veja a próxima seção).

2) Quando você usa allow_other , você também deseja considerar a verificação de permissões. O padrão para o FUSE não é para verificar as permissões. Portanto, apenas adicionar allow_other a um sistema de arquivos pode torná-lo acessível a todos os usuários. Isso é provavelmente indesejável; IDs de usuário separados geralmente são usados para conter serviços, como o daemon de impressora CUPS, no caso de serem comprometidos por ataques de rede. Para permitir verificações de permissões de usuário / grupo / modo em sistemas de arquivos genéricos do FUSE, a opção é chamada default_permissions .

Comportamento específico do NTFS-3G

1 - > De acordo com sua man page, ntfs-3g ativará allow_other por padrão. (Os padrões do FUSE só permitirão que o usuário root faça isso. Não há problema aqui, já que você está usando mount que é executado como root).

2 - > Parece que a ntfs-3g option permissions ativou a verificação de permissão para você. Caso contrário, você não teria notado nenhum erro de permissão. (O SELinux pode fazer, mas você não está usando o SELinux, porque você está no Ubuntu. O Ubuntu AppArmor é descrito como baseado em caminho, então, pelo que você descreveu, acho que é improvável que ele esteja causando um problema).

Tese

Acredito que sua montagem ntfs-3g está configurada para executar verificações de permissão, e o FUSE não está bloqueando separadamente o acesso de outros usuários. Isso parece sensato para uma montagem em fstab , que é usada para fornecer diretórios do sistema como /var/mail .

No entanto, sua mhddfs mount não está realizando verificações de permissão, porque ela não tem default_permissions set. Isso explicaria por que a configuração mhddfs foi capaz de funcionar (apesar das opções para uid,gid,umask , que permitem acesso somente ao seu ID de usuário 1000). Você não mostra os sistemas de arquivos subjacentes, então não sei se eles estão verificando as permissões, mas suspeito que mhddfs esteja simplesmente sendo executado como root e evitando as verificações de permissões dessa maneira.

Aqui está um teste que você pode executar na mhddfs mount. Ele deve mostrar se os bits de permissão estão sendo verificados ou não.

mkdir dir
chmod a-w dir  # make directory read-only
touch dir/t    # attempt writing to directory

Para resolver seus erros de permissão, você precisa determinar quais usuários devem ter o acesso aos arquivos em questão e definir as permissões corretas de acordo. Você nunca disse qual usuário ( ou até mesmo qual software) está falhando nas verificações de permissão, então é difícil ser mais específico.

    
por 02.05.2016 / 21:11