problemas com permissoes de arquivos [RESOLVIDO]

shoujo
(usa Slackware)

Enviado em 16/12/2013 - 20:35h

Olá pessoal, tem 2 servidores linux.

o principal tem uma pasta /arquivos/publico com permissoes 777, o principal é o domínio samba das maquinas windows, e o outro servidor é backup.

O outro servidor é usado por uma funcionaria e ela pode criar arquivos, porem estou tendo problemas com os arquivos que ela cria na maquina de backup.

bom a estrutura esta da seguinte forma:

servidor 1 = /arquivos/publico

servidor 2 = no fstab está: sshfs#root@servidor1:/arquivos/publico /compartilhamentos/publico fuse auto,user,allow_other,noatime,follow_symlinks,delay_connect,reconnect,sshfs_sync 0 0

a funcionaria grava suas informaçoes nessa pasta /compartilhamentos/publico, montada atraves do sshfs

porem os arquivos vem como: dono: root, permissoes: dono acessar e modificar, grupo: acessar, e outros acessar

mas para que o samba aceite funcionar precisa ter permissao 777, como posso resolver isso?

shoujo
(usa Slackware)

Enviado em 17/12/2013 - 12:27h

ninguem?

servicepwm
(usa Slackware)

Enviado em 17/12/2013 - 12:36h

Acho que não entendi muito bem. Você precisa adicionar permissão em uma determinada pasta?
Se for, você pode fazer o seguinte:

sudo chmod 777 /xxx/xxx/xxx 

Buckminster
(usa Debian)

Enviado em 17/12/2013 - 12:37h

Tentou dar permissões recursivas para a pasta no Samba?

chmod -R 777 /pasta/pastas...

E verifique quem é o dono da pasta, se é o root ou se é o grupo do Samba. Talvez tenha que alterar o dono da pasta e/ou o grupo à qual ela pertence.

shoujo
(usa Slackware)

Enviado em 18/12/2013 - 12:36h

Bom vou explicar como está:
usuario1, usuario2
usuario1 entra pelo windows e cria uma pasta no compartilhamento, essa pasta é criada como usuario1 como dono e todos tem acesso ao arquivo e podem escrever nele, ou seja o samba está funcionando corretamente.

usuario 2 cria um arquivo no linux, só que o arquivo é criado como dono: root, permissao apenas de leitura para o grupo e outros usuarios

o usuario2 consegue mecher no arquivo atraves do servidor de backup, porem o usuario1 no windows nao consegue, o arquivo so pode ser lido mas nao pode ser gravado, porem esse usuario consegue criar pastas normais nessa pasta e criar arquivos

resumindo se o arquivo e criado no windows atraves do compartilhamento do samba esta certo, mas do linux atraves do sshfs nao..

imagino que o problema esteja no fstab

ianclever
(usa Arch Linux)

Enviado em 18/12/2013 - 13:12h

deixa eu ver se entendi

vc tem um servidor samba que compartilha uma pasta entre os usuários Windows, e essa pasta tem permissões 777, lá no segundo computador com Linux vc monta essa mesma pasta e aí o usuário Linux tem permissões para escrever na pasta(logicamente devido ou 777), mas os usuários Windows dessa mesma pasta compartilhada não podem alterar o conteúdo, é isso?

caso positivo, a questão é que por mais que a pasta compartilhada esteja com permissões 777, os arquivos criados pelo usuário Linux, tem como dono o usuário que o criou e o grupo do usuário que o criou, e tem as permissões padrão do usuário que o criou que para pastas são 775 e arquivos rw-rw-r--; ou seja os usuários windows se enquadram em "outros", para evitar isso vc pode fazer 2 coisas:

1- mudar como o usuário linux cria permissões para 777, Mas isso é extremamente perigoso pq vai deixá-lo vulnerável

2- ou executar manualmente

 chmod -R 777 /local/da/pasta/samba  

(claro no computador que o samba está rodando), ou criar um script que execute periodicamente este mesmo comando.

Recomendação (se vc ainda não o fez faça):

Se vc está deixando esses arquivos somente na pasta do samba, faça um backup já para uma outra pasta, em um dos linuxes, para uma outra pasta com permissões de 700 pq se algum engraçadinho inventar de entrar nessa pasta do compartilhamento e executar um rm -rf *, já era seus dados pq essa pasta tem permissões 777, para simplificar crie uma rotina que faça isso periodicamente, ou use um servidor de backup que já faz isso sozinho.

shoujo
(usa Slackware)

Enviado em 18/12/2013 - 14:00h

ianclever nao e bem isso nao vou tentar deixar mais claro

servidor1- servidor samba
servidor2- servidor de backup

no servidor1 tem uma pasta /arquivos/publico compartilhada via samba no dominio
todos os usuarios estao no grupo userslocais
essa pasta /arquivos/publico tem como dono root e como grupo userslocais

o samba compartilha para publico essa pasta

no servidor de backup tem um hd para backup..

e tambem tem uma pasta onde é montada a particao via sshfs pelo fstab

um usuario trabalha diretamente so servidor de backup, e os arquivos que cria nessa pasta montada via sshfs, ja analizei a pasta tem permissoes 777, tudo normal.

o que acontece é que quando esse usuario cria o arquivo no servidor de backup nessa pasta compartilhada do sshfs o arquivo é criado como dono root e permissoes apenas para leitura no grupo e outros..

quando um usuario pelo windows cria um arquivo nessa mesma pasta atraves do samba esse arquivo e criado com permissoes totais normalmente

o problem são os arquivos criados no servidor de backup, pq razao que o servidor de backup cria o arquivo com permissao de leitura apenas pro dono? ele devia criar com permissoes totais..

por isso que acho que o problema esta no sshfs montado via fstab...

Buckminster
(usa Debian)

Enviado em 18/12/2013 - 15:05h

Tente assim:

root@servidor1:/arquivos/publico /compartilhamentos/publico fuse -o auto,-o allow_other,-o noatime,-o follow_symlinks,-o delay_connect,-o reconnect,-o sshfs_sync 0 0

E tente também somente retirando o parâmetro "fuse" do início dos parâmetros. Esse parâmetro monta no espaço do usuário e como o kernel do Windows é diferente do Kernel do Linux, pode dar problemas. A não ser que o sshfs tenha suporte para os dois tipos de kerneis, aí já não sei.
Só testando as opções de montagem.

Veja na man page que as opções gerais diferem das opções fuse:
http://linux.die.net/man/1/sshfs

Ou tente dessa maneira:

root@servidor1:/arquivos/publico /compartilhamentos/publico auto,noatime,-o follow_symlinks,-o delay_connect,-o reconnect,-o sshfs_sync, fuse -o allow_other 0 0

Eu não trabalho com sshfs, prefiro nfs ou pvfs, mas estou dando meu pitaco, pois no fundo a sistemática de montagem é a mesma.

shoujo
(usa Slackware)

Enviado em 18/12/2013 - 15:16h

na verdade, esse fuse não está no inicio dos parametros, ele é o tipo de arquivo que o fstab monta, assim como ext4, nas particoes normais, mas vou fazer uns testes e assim que tiver a resposta eu posto resultado

Buckminster
(usa Debian)

Enviado em 18/12/2013 - 15:22h

Pois é, pelo que eu vi aqui não tem esse "fuse" na montagem, mas como você tinha colocado, eu coloquei também.

Veja o que diz o Manuel sobre FUSE:

"SSHFS (Secure Shell FileSystem) é um sistema de arquivos para Linux (e outros sistemas operacionais com uma implementação FUSE, como o Mac OS X ou FreeBSD) capazes de operar em arquivos em um computador remoto usando apenas um login shell seguro no computador remoto. No computador local onde os SSHFS é montado, a implementação faz uso do módulo do kernel FUSE (Filesystem in Userspace). O efeito prático disso é que o usuário final pode facilmente interagir com arquivos remotos sendo servido de forma segura através do SSH como se fossem arquivos locais sobre seu computador. No computador remoto, no subsistema de SFTP, o SSH é usado.
Se o host é um endereço IPv6 numérico, ele precisa estar entre colchetes."

Não fala nada sobre colocar essa opção "fuse", simplesmente vão as opções direto.
Mas o Manuel não especifica muito e como "fuse" é um módulo do kernel, talvez seja preciso chamar ele antes das opções, ou não.

E não, o fuse NÃO é o tipo de arquivos, o sistema de arquivos é o SSHFS. O fuse é um módulo do kernel (Filesystem in Userspace - Sistema de Arquivos no Espaço do Usuário). Ou seja, esse módulo, quando chamado, monta o sistema de arquivos (no caso o SSHFS) no espaço do usuário e não no espaço do kernel.

ianclever
(usa Arch Linux)

Enviado em 18/12/2013 - 16:19h

sim é exatamente o que eu tinha falo, o que vc vai estar fazendo com

 chmod -R 777 /nome/da/pasta/compartilhada  

não é mudar as permissões somente da pasta, o "R" irá mudar as permissões da pasta subpastas e arquivos que estiverem dentro da mesma, assim , vc resolve o problema, isso é problema de permissão, ou se preferir(é mais trabalhoso, mass....) vc pode mudar a permissão de um por um....

isso é uma padrão quando vc cria arquivos como root no linux, não interessa se a pasta superior(ou mãe) está em 777 775, 770, 000 ou qualquer outro ele vai criar com as permissões 733 por padrão e isso será respeitado pelo windows ou outro linux(tanto é que eles só estão podendo ler esses arquivos).

shoujo
(usa Slackware)

Enviado em 19/12/2013 - 12:56h

entendo, então mesmo colocando umask no fstab por causa do arquivo ser criado como usuario root ele continuará criando os arquivos como 733, acho que vou fazer igual vc falou e criar uma rotina no crontab setando 777 a cada minuto na pasta

obrigada pela dica