Git错误：无法附加到.git/logs/refs/remotes/origin/master：权限被拒绝答案

【问题标题】：Git error: Unable to append to .git/logs/refs/remotes/origin/master: Permission deniedGit错误：无法附加到.git/logs/refs/remotes/origin/master：权限被拒绝
【发布时间】：2011-02-08 05:27:51
【问题描述】：

我遇到了一个似乎无法解决的奇怪问题。这是发生了什么：

我在 github 存储库中有一些我不想要的日志文件。我发现这个脚本可以像这样从 git 历史记录中完全删除文件：

    #!/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

我当然是先备份了，然后试了一下。它似乎工作正常。然后我做了一个 git push -f 并收到以下消息：

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

虽然一切似乎都很好，因为文件似乎从 GitHub 存储库中消失了，如果我再次尝试推送，我会得到同样的结果：

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

编辑

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

谢谢！

编辑

哦哦。问题。我整晚都在做这个项目，只是去提交我的更改：

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

所以我：

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

我再次尝试提交，我得到：

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

所以我：

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

然后我再次尝试提交：

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

万岁。我跳上http://GitHub.com 并查看存储库，我的最新提交找不到了。 ::scratch head:: 所以我再推一下：

Everything up-to-date

嗯...看起来不像。我以前从来没有遇到过这个问题，这可能是github的问题吗？还是我的 git 项目搞砸了？

编辑

没关系，我做了一个简单的：

git push origin master

它推得很好。

【问题讨论】：

标签： git github

【解决方案1】：

这看起来像您在本地以 root 身份运行 git，从而更改了一些跟踪 origin 分支位置的文件的所有权。

修复文件所有权，你应该没问题：

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

【讨论】：

那个命令对我有用。我从克隆的根目录运行它。谢谢@CharlesDuffy！
@Mr.Stranger，前提是你有一个健全的 IFS 值和用户名（可能会出现带有空格的用户名，例如在 cygwin 上）。更安全地引用：sudo chown -R "$USER" .，不要假设理智。 :)
@Mr.Stranger, ...另外，USER 不受pubs.opengroup.org/onlinepubs/009695399/utilities/… 的保证，因此使用"$(id -un)" 可能更安全。
它说我的用户is not in the sudoers file. This incident will be reported. - 关于我能做什么的任何提示？谢谢。
上面的语法是parameter expansion； "${var:-default}" 扩展为变量 "$var" 的值，除非该值为空或未设置，在这种情况下它解析为 default。因此，我们要么扩展为"$USER"，要么扩展为运行id -un 生成的输出。

【解决方案2】：

请先授予root 帐户的权限，如下所示

chmod -R 777 foldername

然后运行提交命令

【讨论】：

这是极其危险的——它给系统上的任何帐户，包括只有“nobody”权限的受感染守护程序，对您的文件的写入权限。系统守护程序将“nobody”（或其他非特权帐户）用于安全敏感组件因为即使它受到威胁，nobody 帐户也不应该能够做任何风险太大的事情。通过让所有用户（甚至没有人）拥有对您文件的写入权限，您使基本的安全措施变得毫无用处。
如果出于某种原因您希望您的文件由 root 拥有并且可由特定的非 root 用户写入，那么安全的方法（在每个用户都有自己的组的系统上，如是标准做法）是chown -R root:user directory，然后是chmod -R 775 directory（或770，如果其他帐户也不需要读取权限）。
@JasonGlisson，只有通过创建大量安全漏洞才能“起作用”的东西可能最好还是保持崩溃。
@JasonGlisson，因为我们既作为社区也向社区提供建议，作为社区的一员，我们提供什么样和质量的建议是我的事，和其他人一样——而且，作为从事安全工作的人，我很适合就这个问题发表评论。请参阅最初的评论，回复：影响。
@JasonGlisson, ...至于为什么我的建议对您不起作用，我需要查看详细信息——命令的日志按顺序运行，提示显示当前每个之前的工作目录；发出的任何错误的文本；等等——为了评论；但该讨论的地点将附在您报告不良结果的答案上，而不是在这里。

【解决方案3】：

在我的例子中，我在本地创建了具有 root 权限的文件，并尝试使用本地权限将代码推送到远程。所以我运行了这个命令

$find . -user root

找出所有文件都有“root”作为所有者。然后我使用以下命令将根目录下所有文件的所有者更改为本地文件

$sudo chown parineethat `find . -user root`

然后我可以将我的代码从本地推送到远程。

【讨论】：

sudo chown parineethat `find . -user root` 是不可靠的——不能与带空格的文件名一起使用。相反，sudo find . -user root -exec chown parineethat {} +。相关讨论见BashPitfalls #1。

【解决方案4】：

让我们专注于它究竟在抱怨什么：

权限被拒绝错误：无法更新 ref 'refs/remotes/origin/master'。

在进行递归模式/所有权更改之前，遍历该文件并修复所有不正确的权限。

我想我是通过在我是 root 时创建一个分支然后试图以我的用户身份来搞乱那个分支而导致这个问题的。

【讨论】：

修复除预期拥有整个源代码树的用户以外的任何人拥有的文件真的是一种改进吗？

【解决方案5】：

这将递归地更改您的所有 .git 文件和目录（从根目录到 1000），并为您提供在终端中所做的所有更改的完整列表。

sudo chown -Rc $UID .git/

【讨论】：

【解决方案6】：

我已尝试修复 Git 的所有权，但仍然无法正常工作。

但是，我已经设法通过使用不同的名称创建本地分支并将其删除来修复它。

然后，我再次检查了相同的分支名称，它可以工作。

TLDR;

我无法签出 `staging/rc'。

所以，我使用staging 结帐，而不是遥控器指向 `staging/rc'。

然后，我将其删除并再次结帐。但是，这次我使用staging/rc 作为我的本地分支名称。

它有效，我不知道为什么。

【讨论】：

【解决方案7】：

你可以做一个简单的：

sudo chown -R <username> <folder>

将“用户名”替换为您要授予访问权限的用户，将“文件夹”替换为相对于您执行此命令的位置的文件夹路径

这更像是权限问题的通用解决方案，但我认为这应该会有所帮助。

【讨论】：

【解决方案8】：

如前所述，是因为组或用户设置不正确。

我想补充一下以下命令对隐藏文件夹不起作用的信息：

chown -R user:group *

如果你使用*会失败，你必须设置文件夹的绝对路径，例如：

chown -R user:group /srv/www/vhost/project/

【讨论】：