Não é possível criar arquivos no diretório

Question

Há muitos desses tipos de perguntas sobre o superusuário, por isso vou tentar manter isso rápido, dizendo o que não é:

• Não há aplicativo envolvido aqui. Apenas um usuário e um sistema de arquivos.
• Posso fazer o login como root e meu usuário não root tem acesso total ao sudo.
• Até onde eu sei, esse problema existe apenas em um diretório (embora com tempo suficiente, eu acho que posso recriar esse comportamento em qualquer diretório - mais sobre isso abaixo).
• Sem personalizações de sistemas de arquivos estranhos, aks ou esquemas estranhos de permissão de usuário ou diretório - Eu possuo este sistema, e nenhuma outra pessoa interage com ele.

Esse diretório é um caminho de destino para scripts de backup gravados no bash. Esses scripts não são extravagantes. Rsync arquivos de outro lugar para um diretório de trabalho. Ative todos os arquivos no diretório de trabalho e armazene os arquivos resultantes nesse caminho de destino. Coisas bem simples.

Digamos que esta é uma instalação nova, neste exemplo. O script funciona bem por um tempo. Mas depois de algum período de semanas, nenhum arquivo pode ser criado no caminho de destino, por qualquer usuário, usando qualquer método. Eu tentei tocar, tar, zip, etc Nada funciona. Alcatrão e zip falharão com erros de E / S, o toque funciona bem, mas nenhum arquivo é criado. Nesse caminho de destino e apenas nesse caminho. A criação / modificação / exclusão de arquivos funciona bem em qualquer outro lugar no sistema de arquivos (se estiver acontecendo em outro lugar, é assintomático).

as permissões no diretório se parecem com isso por meio de um ls -al: drwxrwxr-x. - de propriedade do meu usuário não-root e de seu grupo.

Por último, se eu reiniciar o sistema depois que essa condição se apresentar, posso criar arquivos nesse caminho novamente por um curto período de tempo. Eventualmente, porém, o problema retorna.

Quando eu disse que provavelmente posso recriar isso em outro diretório, é porque eu mudei o caminho de destino para outra coisa, tentando consertar isso algumas vezes, e isso eventualmente acontece em todos os locais que eu tentei.

Detalhes do sistema:

• CentOS 2.6.32-431.3.1.el6.x86_64
• Sistema de arquivos é ext4
• 400 GB gratuitos em / (lvm)

Qualquer ideia ou pensamento sobre as coisas para tentar seria muito apreciado. Fico feliz em entrar em mais detalhes, se necessário, mas eu queria manter esta breve para começar.

Obrigado pelo seu tempo!

EDIT 10/20/14: Ainda não há respostas aqui. Posso obter mais informações para alguém?

EDIT 10/8/14: Adicionando informações conforme solicitado nos comentários:
$ ls -l
total 0

$ sudo vgs
  VG #PV #LV #SN Attr VSize VFree
  vg_omega1 1 2 0 wz - n- 464.24g 0

EDITAR 10/7/14: Adicionando informações como solicitado nos comentários:
Resultados da montagem:
/ dev / mapper / vg_omega1-lv_root on / tipo ext4 (rw)
proc on / proc tipo proc (rw)
sysfs on / sys tipo sysfs (rw)
devpts em / dev / pts tipo devpts (rw, gid = 5, mode = 620)
tmpfs em / dev / shm tipo tmpfs (rw, rootcontext="system_u: object_r: tmpfs_t: s0")
/ dev / sda1 on / boot tipo ext4 (rw)
nenhum em / proc / sys / fs / binfmt_misc tipo binfmt_misc (rw)

Caminho:
/ home / [nome de usuário] / savegames / sync

EDIT 10/6/14: Outros testes indicam que aparentemente é possível criar sub-diretórios e links simbólicos muito bem. Este problema parece estar limitado a arquivos regulares.

    

Answer 1

Não posso comentar, pois não tenho o representante, mas vendo sua saída mount , parece que você tem o SELinux em execução. Pela experiência, é difícil rastrear coisas "estranhas" como essas, a menos que você esteja familiarizado com o SELinux. 5+ anos lidando com isso me ensinaram um truque ou dois.

tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")

Você também mencionou que está usando o rsync, e esse problema "desaparece e volta novamente". Suas opções de SELinux estão definidas para serem aplicadas por padrão? (aplicado novamente após uma reinicialização), e você (algumas vezes) está colocando o SELinux no modo permissivo (5 minutos ou 10 dias, etc.) após a reinicialização?

sudo getenforce

Se o resultado for enforcing , e se você tiver o SELinux configurado para ser aplicado por padrão, é provável que você esteja enfrentando negações da política do SELinux.

Ref. o guia de administração do Red Hat 6 - Ch 12 - rsync

Se você

ls -lZ /home/[username]/savegames/sync 

Qual é o rótulo de contexto? Deve ser algo como public_content_t Pode ser user_home_t, o que significa que muitos processos confinados do SELinux terão acesso negado. Haverá mensagens de negação em /var/log/audit/audit.log

Se o SELinux for realmente o culpado, ref guia de solução de problemas do CentOS SELinux para encontrar maneiras de resolver isso. Você poderia:

• Coloque o SELinux no modo permissivo e veja se o seu problema desaparece. Coloque-o de volta no modo de aplicação e seu problema voltará. Não é uma solução a longo prazo, então ...
• Reatore novamente o contexto da pasta / home / [username] / savegames / sync (para public_content_t ou similar) ou
• Crie políticas para permitir que seus scripts / processos funcionem com sua pasta (audit2allow). Isso parece assustador, mas não é impossível.

POR FAVOR. NÃO DESLIGUE O SELINUX.

Bem, tendo dito isso, se você é o único que usa o sistema e não está servindo sites, FTP ou qualquer coisa, tudo bem, talvez deixe-o no modo permissivo, mas boas práticas sugerem que você modifique sua política para dar você é a chave de uma porta, em vez de apenas tirar a porta de suas dobradiças e colocá-la de lado: -)