☰

調試 samba 共享上的 git repo 權限

tag-icon • tag-icon linux permissions git samba
調試 samba 共享上的 git repo 權限

我使用在 samba 共享上克隆的 git 存儲庫已經有大約一年的時間了，除了設定上遇到的一些問題之外，沒有任何問題。最近，我嘗試將一些文件添加到現有存儲庫，並驚訝地看到“權限被拒絕”錯誤。

現在我可以初始化空倉庫，但是當我嘗試運行時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)
    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

我在 64 位元 Archlinux（核心版本：3.12.1）上使用 git 1.8.4.2、samba 4.1.1。多年來我一直沒有更改 git 或 samba 配置中的任何內容。

共享是使用 /etc/fstab 中的 systemd automount 掛載的：

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

安裝顯示為：

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

權限：

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

我已經嘗試過：

  • 設定不同的共享權限 - 相同的結果
  • 手動安裝 - 相同
  • 將 samba 和 git 降級到早期版本 - 沒有區別
  • sudo - 這有效，但除非絕對必要，否則我不想使用它
  • Mercurial (出於好奇) - 克隆 git repo 失敗，hg repos 克隆沒有任何問題
  • 使用 sudo 後更改所有者和群組 - 它們在發出命令之前和之後似乎保持不變

我還能做些什麼來調試它嗎？我很傾向於繼續使用 git，但我不知道權限有什麼問題。

關於須藤：

$ 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

它創建具有權限的物件0755。如果沒有sudo臨時目標文件，則保留0555.看起來問題出在以0444一般使用者身分建立檔案時，似乎具有整個儲存庫的寫入權限。

答案1

最有可能的是，您在 root 期間對此存儲庫進行了更改，可能是使用sudo，現在其中的一些文件.git由 root 擁有。執行以下操作將chown檔案所有權重設為您通常使用的使用者。

答案2

這是3.12中的一個核心錯誤：https://bugzilla.kernel.org/show_bug.cgi?id=66251

按照 @bjauy 的說法降級或升級到 3.13。

答案3

我運行的內核版本有錯誤。我已將核心降級到 3.11.6，並且git add/commit用戶再次開始工作。

答案4

linux 將您的 smb 資料夾視為「其他」群組。因此，如果您希望所有群組都可以寫入您的 www，那麼您的權限應該類似於 xx7，例如 777。

問題是，每次 git 建立新的資料夾、檔案或其他任何內容時，它都會使用自己的權限來建立它。解決方案是使用 umask，這樣以目前使用者的名義建立的所有內容都將使用指定的權限。在這種情況下，Windows 共用資料夾，您將需要這個：

遮罩000

因此任何新檔案都可以被每個人寫入，包括「其他」群組，就是你的共享 Windows 資料夾。

在您的 .bashrc 中加入此 umask，問題就解決了。

相關內容