☰

Debuggen von Git-Repo-Berechtigungen auf Samba-Freigaben

tag-icon • tag-icon linux permissions git samba
Debuggen von Git-Repo-Berechtigungen auf Samba-Freigaben

Ich arbeite seit etwa einem Jahr mit Git-Repositorys, die auf Samba-Freigaben geklont wurden, und abgesehen von ein paar Problemen bei der Einrichtung gab es keine Probleme damit. Vor Kurzem habe ich versucht, einige Dateien zu einem vorhandenen Repository hinzuzufügen, und war überrascht, dass die Fehlermeldung „Zugriff verweigert“ angezeigt wurde.

Jetzt kann ich ein leeres Repository initialisieren, aber beim Versuch, es auszuführen strace git add test, erhalte ich:

    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

Ich verwende Git 1.8.4.2, Samba 4.1.1 auf 64-Bit-Archlinux (Kernelversion: 3.12.1). Ich habe seit Ewigkeiten nichts an der Git- oder Samba-Konfiguration geändert.

Die Freigabe wird mittels systemd automount in /etc/fstab eingehängt:

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

Die Einbindung erfolgt folgendermaßen:

//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)

Berechtigungen:

    $ 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 ..

Ich habe bereits versucht:

  • Festlegen unterschiedlicher Berechtigungen für die Freigabe - dasselbe Ergebnis
  • Montage manuell - gleich
  • Downgrade von Samba und Git auf frühere Versionen - kein Unterschied
  • sudo - das funktioniert, aber ich würde es nur verwenden, wenn es unbedingt nötig ist
  • Mercurial (aus Neugier) - Klonen von Git-Repos schlägt fehl, hg-Repos werden ohne Probleme geklont
  • Ändern des Besitzers und der Gruppe nach der Verwendung von sudo - sie scheinen vor und nach der Ausgabe des Befehls gleich zu bleiben

Kann ich noch etwas tun, um es zu debuggen? Ich bin eher geneigt, bei Git zu bleiben, aber ich habe keine Ahnung, was mit den Berechtigungen nicht stimmt.

Bezüglich 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

Es erstellt die Objekte mit 0755Berechtigungen. Ohne sudotemporäres Objekt bleiben Dateien mit übrig 0555. Das Problem scheint darin zu liegen, die Datei 0444als normaler Benutzer zu erstellen, wasscheintum Schreibberechtigung für das gesamte Repository zu haben.

Antwort1

Höchstwahrscheinlich haben Sie als Root Änderungen an diesem Repository vorgenommen, wahrscheinlich durch die Verwendung von , und nun gehören sudoeinige der Dateien in root. Führen Sie einen aus, um den Dateibesitz auf den Benutzer zurückzusetzen, den Sie normalerweise verwenden..gitchown

Antwort2

Es handelt sich um einen Kernel-Fehler in 3.12:https://bugzilla.kernel.org/show_bug.cgi?id=66251

Downgrade wie von @bjauy erwähnt oder Upgrade auf 3.13.

Antwort3

In der von mir verwendeten Kernelversion gab es einen Fehler. Ich habe den Kernel auf 3.11.6 heruntergestuft und git add/commitals Benutzer konnte ich wieder arbeiten.

Antwort4

Ihr SMB-Ordner wird von Linux als Teil der Gruppe „Andere“ angesehen. Ihre Berechtigungen sollten also etwa xx7 sein, z. B. 777, wenn Sie möchten, dass Ihr WWW von allen Gruppen beschreibbar ist.

Problem: Jedes Mal, wenn Git einen neuen Ordner, eine neue Datei oder etwas anderes erstellt, verwendet es seine eigenen Berechtigungen. Die Lösung besteht darin, umask zu verwenden, sodass alles, was im Namen des aktuellen Benutzers erstellt wird, die angegebenen Berechtigungen verwendet. In diesem Fall benötigen Sie für freigegebene Windows-Ordner Folgendes:

umask 000

Jede neue Datei ist also für jeden beschreibbar, einschließlich der Gruppe „Andere“. Das ist alles, Ihr freigegebener Windows-Ordner.

Fügen Sie diese Umask zu Ihrer .bashrc-Datei hinzu und das Problem ist gelöst.

verwandte Informationen