Por que outros usuários não conseguem ver os arquivos que eu publico no compartilhamento do Samba?


0

Eu corro um servidor Amahi que usa samba e greyhole para compartilhamento de arquivos. Quando copio um arquivo para um dos compartilhamentos, outros não podem vê-lo. Se outro usuário adicionar um arquivo a um compartilhamento, ele será bem-sucedido, mas após a atualização, ele não poderá mais ver o arquivo. O arquivo está no compartilhamento e eu posso ver isso.

Todos os arquivos criados há mais de 4-6 semanas podem ser vistos por qualquer pessoa. Não consegui determinar o que poderia ter mudado. A última reinicialização foi há 60 dias

Isso parece um problema relacionado ao samba, mas não consigo identificá-lo.

Coisas que eu verifiquei: Permissões do Linux - todos os arquivos (/ var / hda / files / tv /) são de propriedade do meu usuário amahi / linux (não root) e do grupo de usuários. Todos os usuários estão no mesmo grupo. Esse grupo tem permissões de RW. Permissões do Samba - o compartilhamento usa permissões de usuários que os usuários têm RW. criar máscara é 0755

Eu corri o fsck do greyhole contra o caminho da TV sem alteração

Aqui estão as permissões atuais de dois arquivos:

    Failed file ( as root)
-rwxrwxr-x 1 gmartin users 205775332 May  4 20:48 /var/hda/files/drives/drive1/gh/TV/SomeShow/SomeShow-S01E02.avi

Successful file (as wdtv)
-rwxrwxr-x 1 gmartin users 257642672 Apr 13 21:55 /var/hda/files/drives/Drive6/gh/TV/SomeShow/SomeShow-S01E05.avi

Informação: Fedora Core 23 Amahi 9.0.0-1 Core 7.0.0-1 samba v 4.3.12 greyhole 0.10.6

Clientes: Win10 (1703), WDTV Live


1
Se você mesmo criar um segundo usuário, será capaz de recriar os problemas sozinho? Qual sistema operacional os clientes estão executando? O servidor de compartilhamento de arquivos está executando o Fedora (você sabe que está desatualizado, certo?)
Ramhound

Vou tentar um novo usuário, mas isso está afetando todos os usuários correntes. Os clientes são Win10 e um WDTV Live (adicionado acima). (O SO do servidor será atualizado neste outono)
uSlackr

Por favor, verifique a saída de ls -lsa no diretório em que você copiou um novo arquivo para verificar se a propriedade e as permissões nesse arquivo estão corretas depois de copiadas. A única outra coisa que eu poderia pensar seria o diretório de compartilhamento nos clientes pode precisar ser atualizado, como eu não acredito que auto-atualização. Além disso, verifique os logs do samba do servidor e do (s) cliente (s).
JW0914

Correu ls -lsa e a propriedade de arquivos bons e ruins é idêntica às permissões.
uSlackr

Respostas:


1

O Greyhole trabalha movendo o arquivo real que você adiciona aos seus compartilhamentos em outro (s) drive (s). Assim, uma vez que Greyhole mova o arquivo e deixe um link simbólico em /var/hda/files/, se seus usuários não tiverem as permissões necessárias para acessar o arquivo que está agora em outra unidade, esses usuários poderão ler o link simbólico, mas não o alvo, e assim o arquivo será oculto pelo Samba.

Entre como um usuário problemático (usando o SSH; use sudo se necessário), e vá ver um symlink em /var/hda/files/ que esse usuário não vê no compartilhamento. Observe o alvo desse link simbólico e tente acessar esse arquivo. Você provavelmente vai achar que você não pode. Você provavelmente precisa chown/chmod -R todas as suas unidades de dados (são aquelas ainda montadas em /var/hda/drives?)

Atualizar: Eu adicionei uma página no wiki sobre isso, com exemplos: https://github.com/gboudreau/Greyhole/wiki/Permissions-Data-Drives

Atualização 2: Tente isto:

$ chown -R gb:users /var/hda/files/drives/*
$ find /var/hda/files/drives/* -type d -exec chmod 775 "{}" \; # Permissions for directories
$ find /var/hda/files/drives/* -type f -exec chmod 664 "{}" \; # Permissions for files

mudança gb:users, 775 e 664 como necessário.


De fato, um dos usuários não pode acessar os arquivos "ruins". Quais permissões devo redefinir (chown / chmod) para? Vou adicionar dois exemplos de um arquivo de trabalho e não-trabalho para a questão.
uSlackr

Nevermind - Estou lendo a página wiki. desculpa
uSlackr

Irã $ chown -R gmartin:users /var/hda/drive/*/gh $ chmod -R g+w /var/hda/drives/*/gh e o usuário de teste ainda recebe permissions denied
uSlackr

1
chmod -R g+w provavelmente não foi o suficiente para você, já que seus usuários não podem nem "ver" os arquivos. Você precisa dar o grupo rwx (ou r-x ) Acesso. Veja minha resposta atualizada para exemplos.
Guillaume Boudreau

1
Usando o SSH, faça o login como essa conta de usuário e tente cd na pasta problemática (em uma unidade de dados), um nível por vez: cd /var/; cd hda; cd files; ...; cd drive1... cd SomeShow. Isso mostrará a você em que nível as permissões problemáticas são.
Guillaume Boudreau
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.