Lỗi git: Không thể thêm vào .git / logs / refs / remotes / origin / master: Quyền bị từ chối


87

Tôi đang gặp một vấn đề lạ mà dường như tôi không thể giải quyết được. Đây là những gì đã xảy ra:

Tôi có một số tệp nhật ký trong kho lưu trữ github mà tôi không muốn ở đó. Tôi đã tìm thấy tập lệnh này xóa hoàn toàn các tệp khỏi lịch sử git như vậy:

    #!/bin/bash
set -o errexit

# Author: David Underhill
# Script to permanently delete files/folders from your git repository.  To use 
# it, cd to your repository's root and then run the script with a list of paths
# you want to delete, e.g., git-delete-history path1 path2

if [ $# -eq 0 ]; then
    exit 0are still
fi

# make sure we're at the root of git repo
if [ ! -d .git ]; then
    echo "Error: must run this script from the root of a git repository"
    exit 1
fi

# remove all paths passed as arguments from the history of the repo
files=$@
git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch $files" HEAD

# remove the temporary history git-filter-branch otherwise leaves behind for a long time
rm -rf .git/refs/original/ && git reflog expire --all &&  git gc --aggressive --prune

Tất nhiên, tôi đã sao lưu trước và sau đó thử nó. Nó dường như hoạt động tốt. Sau đó, tôi đã thực hiện git push -f và được chào đón bằng các thông báo sau:

error: Unable to append to .git/logs/refs/remotes/origin/master: Permission denied
error: Cannot update the ref 'refs/remotes/origin/master'.

Mặc dù vậy, mọi thứ dường như đã diễn ra tốt đẹp, vì các tệp dường như đã biến mất khỏi kho lưu trữ GitHub, nếu tôi thử và đẩy lại, tôi nhận được điều tương tự:

error: Unable to append to .git/logs/refs/remotes/origin/master: Permission denied
error: Cannot update the ref 'refs/remotes/origin/master'.
Everything up-to-date

BIÊN TẬP

$ sudo chgrp {user} .git/logs/refs/remotes/origin/master
$ sudo chown {user} .git/logs/refs/remotes/origin/master
$ git push
Everything up-to-date

Cảm ơn!

BIÊN TẬP

Ồ. Vấn đề. Tôi đã làm việc với dự án này cả đêm và chỉ cần thực hiện các thay đổi của mình:

error: Unable to append to .git/logs/refs/heads/master: Permission denied
fatal: cannot update HEAD ref

Vì vậy, tôi:

sudo chown {user} .git/logs/refs/heads/master
sudo chgrp {user} .git/logs/refs/heads/master

Tôi thử lại cam kết và nhận được:

error: Unable to append to .git/logs/HEAD: Permission denied
fatal: cannot update HEAD ref

Vì vậy, tôi:

sudo chown {user} .git/logs/HEAD
sudo chgrp {user} .git/logs/HEAD

Và sau đó tôi thử lại cam kết:

16 files changed, 499 insertions(+), 284 deletions(-)
create mode 100644 logs/DBerrors.xsl
delete mode 100644 logs/emptyPHPerrors.php
create mode 100644 logs/trimXMLerrors.php
rewrite public/codeCore/Classes/php/DatabaseConnection.php (77%)
create mode 100644 public/codeSite/php/init.php
$ git push
Counting objects: 49, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (27/27), done.
Writing objects: 100% (27/27), 7.72 KiB, done.
Total 27 (delta 15), reused 0 (delta 0)
To git@github.com:IAmCorbin/MooKit.git
59da24e..68b6397  master -> master

Hoan hô. Tôi nhảy vào http://GitHub.com và kiểm tra kho lưu trữ, và cam kết mới nhất của tôi không tìm thấy ở đâu. :: gãi đầu :: Vì vậy, tôi đẩy một lần nữa:

Everything up-to-date

Ừm ... không giống đâu. Tôi chưa bao giờ gặp vấn đề này trước đây, đây có thể là vấn đề với github? hay tôi đã làm gì đó với dự án git của tôi bị rối tung lên?

BIÊN TẬP

Đừng bận tâm, tôi đã làm một việc đơn giản:

git push origin master

và nó hoạt động tốt.

Câu trả lời:


216

Điều này có vẻ như bạn đã chạy git với tư cách là root cục bộ, do đó thay đổi quyền sở hữu trên một số tệp theo dõi vị trí của originchi nhánh.

Sửa quyền sở hữu tệp và bạn sẽ ổn:

# run this from the root of the git working tree
sudo chown -R "${USER:-$(id -un)}" .

1
Lệnh đó đã làm việc cho tôi. Tôi chạy nó từ gốc của bản sao. Cảm ơn @CharlesDuffy!
ariestav

4
@ Mr.Stranger, chỉ khi bạn có giá trị IFS và tên người dùng lành mạnh (tên người dùng có dấu cách có thể xảy ra, chẳng hạn như trên cygwin). An toàn hơn để trích dẫn:, sudo chown -R "$USER" .và không giả định sự tỉnh táo. :)
Charles Duffy

@ Mr.Stranger, ... cũng USERkhông được bảo đảm bởi pubs.opengroup.org/onlinepubs/009695399/utilities/… , vì vậy có thể sử dụng an toàn hơn "$(id -un)".
Charles Duffy

Nó cho biết người dùng của tôi is not in the sudoers file. This incident will be reported.- bất kỳ mẹo nào về những gì tôi có thể làm? Cảm ơn.
giovannipds

1
Cú pháp trên là mở rộng tham số ; "${var:-default}"mở rộng thành giá trị của biến "$var", trừ khi giá trị đó trống hoặc không được đặt, trong trường hợp đó, nó sẽ giải quyết thành default. Do đó, chúng tôi mở rộng đến "$USER", hoặc đầu ra được tạo ra bằng cách chạy id -un.
Charles Duffy

3

Hãy tập trung vào những gì nó phàn nàn chính xác:

Lỗi bị từ chối cấp quyền: Không thể cập nhật bản giới thiệu 'refs / remotes / origin / master'.

Trước khi thực hiện các thay đổi quyền sở hữu / mod đệ quy, hãy xem theo cách của bạn đến tệp đó và sửa bất kỳ quyền nào không chính xác.

Tôi nghĩ rằng tôi đã gây ra sự cố này bằng cách tạo một nhánh trong khi tôi root và sau đó cố gắng gây rối với nhánh đó với tư cách là người dùng của tôi.


3
Việc sửa các tệp thuộc sở hữu của bất kỳ ai khác ngoài người dùng được kỳ vọng sở hữu toàn bộ cây nguồn có thực sự là một cải tiến không?
Charles Duffy

2

Trong trường hợp của tôi, tôi đã tạo các tệp với quyền root cục bộ và cố gắng đẩy mã đến từ xa với quyền cục bộ. Vì vậy, tôi đã chạy lệnh này

$find . -user root

để tìm hiểu xem tất cả các tệp có "root" là chủ sở hữu. Và sau đó, tôi đã thay đổi chủ sở hữu cho tất cả các tệp dưới quyền root thành cục bộ bằng cách sử dụng lệnh sau

$sudo chown parineethat `find . -user root`

Sau đó, tôi đã có thể đẩy mã của mình từ cục bộ sang từ xa.


sudo chown parineethat `find . -user root` là không đáng tin cậy - sẽ không hoạt động đúng với tên tệp có khoảng trắng. Thay vào đó sudo find . -user root -exec chown parineethat {} +,. Xem BashPitfalls # 1 để biết thảo luận có liên quan.
Charles Duffy

1

Điều này sẽ thay đổi tất cả các tệp .git và thư mục của bạn một cách đệ quy (từ gốc đến 1000) và cung cấp cho bạn danh sách đầy đủ tất cả các thay đổi được thực hiện trong thiết bị đầu cuối.

sudo chown -Rc $ UID .git /


0

Tôi đã thử sửa quyền sở hữu cho Git, nhưng nó vẫn không hoạt động.

Nhưng, tôi đã cố gắng sửa nó bằng cách tạo nhánh cục bộ với một tên khác và xóa nó.

Sau đó, tôi kiểm tra lại tên chi nhánh giống nhau và nó hoạt động.

TLDR;

Tôi không thể kiểm tra `staging / rc '.

Vì vậy, stagingthay vào đó tôi kiểm tra bằng cách sử dụng điều khiển từ xa trỏ tới `staging / rc '.

Và, tôi xóa nó và thanh toán lại. Nhưng, lần này tôi sử dụng staging/rclàm tên chi nhánh địa phương của mình.

Nó hoạt động và tôi không biết tại sao.


-16

Trước tiên hãy cấp quyền từ roottài khoản như bên dưới

chmod -R 777 foldername

sau đó chạy lệnh cam kết


7
Điều này cực kỳ nguy hiểm - nó cấp cho bất kỳ tài khoản nào trên hệ thống, kể cả daemon bị xâm nhập chỉ có đặc quyền "không ai cả", quyền ghi vào các tệp của bạn. Daemon hệ thống sử dụng "không ai" (hoặc các tài khoản không có đặc quyền khác) cho các thành phần nhạy cảm về bảo mật tài khoản không ai được cho là không thể thực hiện bất kỳ điều gì quá rủi ro ngay cả khi nó bị xâm phạm. Bằng cách cho phép tất cả người dùng, thậm chí không ai, có quyền ghi vào tệp của bạn, bạn đang khiến các biện pháp bảo mật thiết yếu trở nên vô dụng.
Charles Duffy

1
Nếu vì lý do nào đó mà bạn muốn các tệp của mình thuộc quyền sở hữu của root và có thể ghi được bởi một người dùng không phải root cụ thể, thì cách an toàn để làm điều đó (trên hệ thống mà mỗi người dùng có nhóm riêng của họ, như thông lệ tiêu chuẩn) là chown -R root:user directory, và sau đó chmod -R 775 directory(hoặc 770nếu các tài khoản khác cũng không cần quyền truy cập đọc).
Charles Duffy

1
@JasonGlisson, một thứ chỉ "hoạt động" bằng cách tạo ra các lỗ hổng bảo mật lớn có lẽ là thứ tốt hơn hết nếu không bị hỏng.
Charles Duffy

1
@JasonGlisson, mặc dù chúng tôi đang cung cấp lời khuyên cho cả cộng đồng và cho cộng đồng, với tư cách là thành viên của cộng đồng đó, loại và chất lượng lời khuyên mà chúng tôi cung cấp là doanh nghiệp của tôi giống như bất kỳ ai khác - và với tư cách là một người làm việc trong lĩnh vực bảo mật , Tôi có đủ khả năng để bình luận về chủ đề này. Xem nhận xét ban đầu, re: Impact.
Charles Duffy

1
@JasonGlisson, ... về lý do tại sao lời khuyên của tôi không phù hợp với bạn, tôi cần xem chi tiết - nhật ký các lệnh chạy, theo thứ tự, với lời nhắc hiển thị thư mục làm việc hiện tại trước mỗi lệnh; văn bản của bất kỳ lỗi phát ra; vv - để bình luận; nhưng vị trí cho cuộc thảo luận đó sẽ được đính kèm với câu trả lời mà bạn đang báo cáo kết quả xấu, trái ngược với ở đây.
Charles Duffy
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.