☰

Depurando permissões do repositório git no compartilhamento do samba

tag-icon • tag-icon linux permissions git samba
Depurando permissões do repositório git no compartilhamento do samba

Tenho trabalhado com repositórios git clonados no compartilhamento de samba há cerca de um ano e, além de alguns problemas com a configuração, não houve problemas com ele. Recentemente tentei adicionar alguns arquivos ao repositório existente e fiquei surpreso ao ver erros de "permissão negada".

Agora consigo iniciar o repositório vazio, mas quando tento executar strace git add test, recebo:

    open(".git/objects/info/alternates", O_RDONLY|O_NOATIME) = -1 ENOENT (No such file or directory)
    access(".git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391", F_OK) = -1 ENOENT (No such file or directory)
    open(".git/objects/e6/tmp_obj_GvIyn7", O_RDWR|O_CREAT|O_EXCL, 0444) = -1 EACCES (Permission denied)
    write(2, "error: insufficient permission f"..., 88error: insufficient permission for adding an object to repository database .git/objects
    ) = 88
    close(4)                                = 0
    write(2, "error: test: failed to insert in"..., 44error: test: failed to insert into database
    ) = 44
    write(2, "error: unable to index file test"..., 33error: unable to index file test
    ) = 33

Estou usando git 1.8.4.2, samba 4.1.1 no Archlinux de 64 bits (versão do kernel: 3.12.1). Não tenho mudado nada na configuração do git nem do samba há muito tempo.

O compartilhamento é montado usando o systemd automount em /etc/fstab:

//SERVER/DATA  /media/smb  cifs user,noauto,credentials=/etc/samba/creds,\
workgroup=PRV,uid=1000,gid=users,_netdev,comment=systemd.automount 0 0

montagem aparece como:

//SERVER/DATA on /media/smb type cifs (rw,nosuid,nodev,noexec,relatime,vers=1.0,
cache=strict,domain=PRV,uid=1000,forceuid,gid=100,forcegid,addr=10.1.1.5,
file_mode=0755,dir_mode=0755,nounix,serverino,rsize=61440,wsize=65536,actimeo=1)

Permissões:

    $ ls -lan .git/objects
    total 0
    drwxr-xr-x 2 1000 100 0 11-27 09:04 .
    drwxr-xr-x 2 1000 100 0 2013-11-27  ..
    drwxr-xr-x 2 1000 100 0 11-27 09:39 e6
    drwxr-xr-x 2 1000 100 0 11-27 09:04 info
    drwxr-xr-x 2 1000 100 0 11-27 09:04 pack

    $ ls -lan .git/objects/pack
    total 0
    drwxr-xr-x 2 1000 100 0 11-27 09:04 .
    drwxr-xr-x 2 1000 100 0 11-27 09:04 ..

Eu já tentei:

  • definindo permissões diferentes para compartilhamento - mesmo resultado
  • montagem manualmente - mesmo
  • fazendo downgrade do samba e do git para versões anteriores - sem diferença
  • sudo - isso funciona, mas eu não gostaria de usá-lo a menos que seja absolutamente necessário
  • mercurial (por curiosidade) - a clonagem do repositório git falha, os repositórios hg são clonados sem problemas
  • mudando o proprietário e o grupo depois de usar o sudo - eles parecem permanecer os mesmos antes e depois de emitir o comando

Há mais alguma coisa que eu possa fazer para depurá-lo? Estou bastante inclinado a continuar com o git, mas não tenho ideia do que há de errado com as permissões.

Em relação ao sudo:

$ touch test
$ sudo strace git add test
open(".git/objects/info/alternates", O_RDONLY|O_NOATIME) = -1 ENOENT (No such file or directory)
access(".git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, ".git/objects/pack", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
getdents(5, /* 2 entries */, 32768)     = 48
getdents(5, /* 0 entries */, 32768)     = 0
close(5)                                = 0
open(".git/objects/e6/tmp_obj_i4e0C8", O_RDWR|O_CREAT|O_EXCL, 0444) = 5
brk(0xd5a000)                           = 0xd5a000
write(5, "x\1K\312\311OR0`\0\0\t\260\1\360", 15) = 15
brk(0xd4a000)                           = 0xd4a000
brk(0xd3a000)                           = 0xd3a000
close(5)                                = 0
link(".git/objects/e6/tmp_obj_i4e0C8", ".git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391") = 0
unlink(".git/objects/e6/tmp_obj_i4e0C8") = 0
lstat(".git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391", {st_mode=S_IFREG|0755, st_size=15, ...}) = 0
close(4)   

$ ls -lan .git/objects/e6
total 1
drwxr-xr-x 2 1000 100  0 11-28 10:11 .
drwxr-xr-x 2 1000 100  0 11-28 10:10 ..
-rwxr-xr-x 1 1000 100 15 11-28 10:11 9de29bb2d1d6434b8b29ae775ad8c2e48c5391
-r-xr-xr-x 1 1000 100  0 11-28 10:11 tmp_obj_9Z8UgU
-r-xr-xr-x 1 1000 100  0 11-28 10:10 tmp_obj_d0yhDJ

Ele cria os objetos com 0755permissões. Sem sudoobjetos temporários, os arquivos ficam com a extensão 0555. Parece que o problema está na criação de arquivo com 0444um usuário normal, o quepareceter permissões de gravação em todo o repositório.

Responder1

Provavelmente, você fez alterações neste repositório enquanto era root, provavelmente usando sudo, e agora alguns dos arquivos .gitpertencem ao root. Faça um chownpara redefinir a propriedade do arquivo para o usuário que você costuma usar.

Responder2

É um bug do kernel no 3.12:https://bugzilla.kernel.org/show_bug.cgi?id=66251

Faça downgrade conforme mencionado por @bjauy ou atualize para 3.13.

Responder3

Houve um bug na versão do kernel que eu estava executando. Fiz o downgrade do kernel para 3.11.6 e git add/commitquando o usuário começou a trabalhar novamente.

Responder4

sua pasta smb é vista pelo Linux como no grupo "outros". Portanto, suas permissões devem ser algo como xx7, por exemplo, 777 se você deseja que seu www seja gravável por todos os grupos.

Problema, toda vez que o git cria uma nova pasta, arquivo ou qualquer outra coisa, ele o cria usando suas próprias permissões. A solução é usar umask, assim tudo que for criado no nome do usuário atual utilizará as permissões especificadas. Nesse caso, pasta compartilhada do Windows, você precisará disto:

umask 000

portanto, qualquer novo arquivo poderá ser gravado por todos, incluindo o grupo "outros", é isso, sua pasta compartilhada do Windows.

Adicione este umask no seu .bashrc e o problema será resolvido.

informação relacionada