Se o Deluge estiver criando os arquivos, é aí que você precisa alterar as permissões. Uma solução é usar ACLs , outra é alterar o umask para o deluge service e adicione usuários ao grupo de serviços.
Meu sistema é configurado com uma instalação do Ubuntu 14.04 executando uma máquina virtual 14.04 guest, via Virtual Box da Oracle.
Eu também tenho 3 x 2TB unidades de instalação em um zpool. Para dar acesso à máquina virtual aos conjuntos de dados no zpool, usei os recursos de pastas compartilhadas do Virtual Box para compartilhar / mnt / [datasets] com a máquina virtual. Dentro da máquina virtual, eles estão disponíveis como / media / sf_ [conjuntos de dados].
Eu uso a máquina virtual para a maioria das atividades do meu servidor, incluindo a execução de dilúvio e sickbeard (tecnicamente sickrage). A configuração My Sickrage procura por torrents e os deposita em uma pasta em / media / sf_dataset1 / torrentfolder, que é monitorada por dilúvio e faz o download real em / media / sf_dataset1 / torrentsdownloaded. Sickrage monitora torrentsdownloaded e publica processos em / media / sf_dataset2 / Television.
Fora da máquina virtual, na instalação "base" do Ubuntu, tenho um servidor plex em execução e monitora / mnt / dataset2 / [Media Folders].Eu apenas mudei para essa configuração e notei que o Plex não estava encontrando novas mídias, apesar de estar no lugar certo. Isso me levou a verificar as permissões. Após o download, os arquivos têm permissões de:
Owner - Read/Write
Group - Read/Write
Others - Read Only
E, como isso está dentro da máquina virtual, o proprietário é root e o grupo é vboxsf.
Após os processos de postagem do Sickrage, as permissões mudam para
Owner - Read/Write
Group - Read/Write
Others - None
Acho que isso ocorre porque o Sickrage concede permissões a arquivos com base nas permissões do diretório em que o arquivo é colocado. E como essas são pastas compartilhadas, todas elas têm permissões de 770 e não posso alterá-las para 777 (tentei).
Fora da máquina virtual, as permissões nos arquivos baixados e nos arquivos pós-processados são os mesmos. O proprietário e o grupo são [usuário]: [grupo de usuários]. Então o Plex não tem permissões e não está vendo os arquivos.
Uma correção para isso é chmod 777 os arquivos transferidos. Mas eu não quero fazer isso manualmente (todo o sistema deve ser automatizado). Mas minha ideia para uma solução automatizada era um crontab em conjunto com um script para
chmod 777 -R /mnt/dataset2
a cada minuto. Estou preocupado que isso possa danificar minhas unidades de muitas gravações e leituras.
Outra solução é que eu poderia mudar o proprietário de todos os arquivos para [user]: plex. Se eu fizer isso, acho que os futuros arquivos pós-processados seriam, então, 770, com um proprietário de usuário e um grupo de plex. Como o user plex, que executa o servidor plex, é um membro do grupo plex, ele cuida dos problemas de permissão. O único problema aqui é que eu acho que teria que mudar o dilúvio para rodar como usuário plex. Caso contrário, meus arquivos seriam baixados com a propriedade [usuário]: [grupo de usuários].
Ainda assim, queria ressaltar isso da comunidade e ver o que eles dizem. O meu chmod 777 a cada minuto causaria estresse indevido no meu sistema ou unidades?
Existe alguma desvantagem em tornar o plex proprietário de todos os meus arquivos assim? Eu vou ter que reconfigurar o dilúvio?
Talvez uma terceira opção seja tornar o usuário plex um membro do [grupo de usuários]. Mas isso daria acesso a muitos arquivos e não parece ideal.
EDITAR:
Eu consegui remover algumas especulações. O fato de que isso está acontecendo em uma VM não parece importar. Eu tenho CouchPotato similarmente renomeando e movendo arquivos de filme. Depois de serem processados pelo CouchPotato, os arquivos aparecem com permissões viáveis.
Isso significa que deve haver algo estranho em SickBeard. Eu postei em um fórum específico do Sickbeard.
Se o Deluge estiver criando os arquivos, é aí que você precisa alterar as permissões. Uma solução é usar ACLs , outra é alterar o umask para o deluge service e adicione usuários ao grupo de serviços.
Oi, acho que a resposta está em entender quais sistemas estão gravando em seus dados de onde e como eles acessam. Ou seja conectar-se através de smb ou afp cria cenários diferentes e a conexão por meio do NFS é diferente novamente. Se você estiver usando afp, eu recomendaria mudar para o smb e se você está se conectando através do NFS você precisa combinar o uid e o gid corretamente.
Além disso, se eu estiver lendo corretamente, você também terá uma máquina virtual conectada por meio de algum compartilhamento nativo de VMs. A menos que tenha opções para o usuário, grupo e modo padrão, eu o evitaria e apenas configuraria com a rede do sistema operacional, usando, por exemplo, NFS acima. Dessa forma, você pode controlar apenas quem seu sistema de mídia acha que está gravando seus dados e quais permissões padrão são necessárias, mantendo a consistência sobre eles. Acabei de escrever um guia sobre o Tech-KnowHow que cobre a maior parte deste ontem, o que pode ajudar. Deixe-me saber se isso não funciona, pois ainda é relativamente fresco em minha mente e eu posso ser capaz de acrescentar algo mais. Boa sorte.
Link direto: link
** Atualização em 27 de abril de 2016 ** Eu voltei para ver como você estava se saindo, não parece que você resolveu isso ainda? Eu vejo sua atualização sobre o Sickbeard e ainda estou convencido de que isso é relacionado ao nível do SO, em vez de específico do aplicativo. Você teve alguma sorte com o Sickbeard ainda? As permissões do Linux são um verdadeiro problema.
Há, claro, as ACLs, que são um pouco mais fáceis de entender, mas também funcionam com permissões padrão do Linux quando você as vê.
Marshalleq