setquota falha silenciosamente

1

Estou tentando definir uma cota de sistema de arquivos para vários usuários no meu sistema com um comando como:

setquota -b /mntpnt < /file/with/quotas

Isso parece funcionar para quase todos os usuários. No entanto, quando faço isso:

getent passwd 
  | awk -F: '{ if ($3 >=1000 && $3 < 2000) print $1 }' 
  | xargs quota -u 
  | grep 'none' 
  | awk '{print $5}'

para imprimir os nomes dos usuários que não têm uma cota definida para eles, esse pipeline relata dois usuários cujos nomes foram incluídos em /file/with/quotas . Eu até tentei definir suas cotas manualmente por meio de um comando como:

setquota -u user 1024 1024 0 0 /mntpnt

Isto não reporta nada (como esperado) e dá um status de saída zero. No entanto, quota -u user ainda informa que esse usuário não tem cotas ativadas.

Tanto quanto eu posso ver, não há nada especial sobre as duas contas de desonestos que as diferenciam.

Posso tornar setquota mais detalhado? Eu tentei strace ing mas isso não produziu nenhuma informação nova. Alguma sugestão sobre por que isso pode estar se comportando assim?

Versão de cota do kernel: 6.5.1
SO: Debian Squeeze 6.0.1
FS: ext4

Atualizar

Eu removi /mntpnt/aquota.user e recriou-o com quotacheck -c /mntpnt porque eu tinha outros motivos para pensar que ele estava corrompido. Todos os sintomas descritos acima ocorreram com o novíssimo aquota.user .

    
por Joseph R. 14.04.2014 / 18:30

1 resposta

0

Eu tive um problema semelhante no passado no ext3. O arquivo de cota foi danificado silenciosamente e criou esse cenário estranho. Definir a cota do usuário como zero e voltar também não corrigiu.

O arquivo em questão é /path/to/mountpoint/aquota.user.

O que acabamos fazendo foi desativar as cotas, excluir esse arquivo, voltar as cotas e redigitar o sistema para obter os dados da cota corretos novamente. Desde que fizemos isso, o problema não apareceu novamente por mais de três anos.

O comando para redigitalizar a cotação depois de fazer isso é quotacheck -cuvf /path/to/mountpoint .

Esta é realmente uma abordagem de choque e pavor. Este é realmente um bug no upstream, mas depois de duas semanas tentando consertá-lo, essa abordagem era muito razoável.

    
por 14.04.2014 / 23:41

Tags