HgWebDir 推送权限被拒绝错误
我有一个新的 Fedora 12 服务器，我正在尝试在其上设置 Mercurial。我已经安装了 Mercurial，并且大多数事情似乎都工作正常。但是，通过 apache 设置 hgwebdir.cgi 后，我无法对当前托管的唯一存储库执行 hg Push 。我得到的错误是：
searching for changes
abort: HTTP Error 500: Permission denied: .hg/store/lock
httpd 正在以用户 apache 身份运行
UID PID PPID C STIME TTY TIME CMD
root 1691 1 0 13:19 ? 00:00:00 /usr/sbin/httpd
apache 1694 1691 0 13:19 ? 00:00:00 /usr/sbin/httpd
apache 1695 1691 0 13:19 ? 00:00:00 /usr/sbin/httpd
apache 1696 1691 0 13:19 ? 00:00:00 /usr/sbin/httpd
apache 1697 1691 0 13:19 ? 00:00:00 /usr/sbin/httpd
apache 1698 1691 0 13:19 ? 00:00:00 /usr/sbin/httpd
apache 1699 1691 0 13:19 ? 00:00:00 /usr/sbin/httpd
apache 1700 1691 0 13:19 ? 00:00:00 /usr/sbin/httpd
apache 1701 1691 0 13:19 ? 00:00:00 /usr/sbin/httpd
，并且我设置了权限，以便 apache 用户拥有整个存储库和所有内容。在最后的尝试中，我什至使该存储库可全局写入。
[root@builds .hg]# ll
total 424K
drwxrwxrwx. 3 apache apache 4.0K 2010-04-19 14:43 .
drwxrwxrwx. 19 apache apache 4.0K 2010-04-15 13:33 ..
-rw-rw-rw-. 2 apache apache 57 2010-04-13 11:42 00changelog.i
-rw-rw-rw-. 1 apache apache 93 2010-04-16 15:33 branchheads.cache
-rw-rw-rw-. 1 apache apache 192K 2010-04-15 13:33 dirstate
-rw-r--r--. 1 apache apache 156 2010-04-19 14:43 hgrc
-rw-rw-rw-. 1 apache apache 42 2010-04-15 13:33 last-message.txt
-rw-rw-rw-. 2 apache apache 23 2010-04-13 11:42 requires
drwxrwxrwx. 4 apache apache 4.0K 2010-04-19 11:26 store
-rw-rw-rw-. 1 apache apache 45 2010-04-14 14:08 tags.cache
-rw-rw-rw-. 1 apache apache 7 2010-04-16 15:33 undo.branch
-rw-rw-rw-. 1 apache apache 192K 2010-04-16 15:33 undo.dirstate
[root@builds .hg]# cd store
[root@builds store]# ll
total 308K
drwxrwxrwx. 4 apache apache 4.0K 2010-04-19 11:26 .
drwxrwxrwx. 3 apache apache 4.0K 2010-04-19 14:43 ..
-rw-rw-rw-. 1 apache apache 20K 2010-04-16 15:33 00changelog.i
-rw-rw-rw-. 1 apache apache 81K 2010-04-16 15:33 00manifest.i
drwxrwxrwx. 17 apache apache 4.0K 2010-04-13 11:47 data
drwxrwxrwx. 3 apache apache 4.0K 2010-04-13 11:43 dh
-rw-rw-rw-. 2 apache apache 177K 2010-04-15 11:03 fncache
-rw-rw-rw-. 1 apache apache 67 2010-04-16 15:33 undo
我在机器上的其他地方有一个以不同用户身份运行的存储库的克隆。如果我将克隆 hgrc 文件的 [paths] 部分中的 default 值设置为服务器上的本地文件路径，则推送工作正常，但如果我切换它使用 url 时，我每次都会收到错误。
我的设置方式可能存在一些怪癖... hgwebdir.cgi 位于 /var/www/cgi-bin 中，而存储库是 /opt/hg< 的子级/代码>。我也关闭了suexec，这似乎并不能解决问题。我在 apache 配置中添加的用于运行 hgwebdir 的唯一行是：
ScriptAlias /hg "/var/www/cgi-bin/hgwebdir.cgi"
hgweb.config 也在 /var/www/cgi-bin 中，其内容是：
[collections]
/opt/hg = /opt/hg
[trusted]
users = *
[web]
baseurl = /hg
push_ssl = false
allow_push = *
The repo browser is running fine, it's只是推动那是行不通的。 Apache error_log 根本没有任何关于此错误的信息。
I have a new Fedora 12 server that I am attempting to set up Mercurial on. I have yum installed mercurial, and most things seem to work fine. However, after setting up hgwebdir.cgi through apache, I am unable to do an hg push to the only repo currently being hosted. The error I get back is:
searching for changes
abort: HTTP Error 500: Permission denied: .hg/store/lock
httpd is running as user apache
UID PID PPID C STIME TTY TIME CMD
root 1691 1 0 13:19 ? 00:00:00 /usr/sbin/httpd
apache 1694 1691 0 13:19 ? 00:00:00 /usr/sbin/httpd
apache 1695 1691 0 13:19 ? 00:00:00 /usr/sbin/httpd
apache 1696 1691 0 13:19 ? 00:00:00 /usr/sbin/httpd
apache 1697 1691 0 13:19 ? 00:00:00 /usr/sbin/httpd
apache 1698 1691 0 13:19 ? 00:00:00 /usr/sbin/httpd
apache 1699 1691 0 13:19 ? 00:00:00 /usr/sbin/httpd
apache 1700 1691 0 13:19 ? 00:00:00 /usr/sbin/httpd
apache 1701 1691 0 13:19 ? 00:00:00 /usr/sbin/httpd
and I set permissions so that the apache user owns the whole repo and everything. In a last ditch attempt, I even made the repo globally writable.
[root@builds .hg]# ll
total 424K
drwxrwxrwx. 3 apache apache 4.0K 2010-04-19 14:43 .
drwxrwxrwx. 19 apache apache 4.0K 2010-04-15 13:33 ..
-rw-rw-rw-. 2 apache apache 57 2010-04-13 11:42 00changelog.i
-rw-rw-rw-. 1 apache apache 93 2010-04-16 15:33 branchheads.cache
-rw-rw-rw-. 1 apache apache 192K 2010-04-15 13:33 dirstate
-rw-r--r--. 1 apache apache 156 2010-04-19 14:43 hgrc
-rw-rw-rw-. 1 apache apache 42 2010-04-15 13:33 last-message.txt
-rw-rw-rw-. 2 apache apache 23 2010-04-13 11:42 requires
drwxrwxrwx. 4 apache apache 4.0K 2010-04-19 11:26 store
-rw-rw-rw-. 1 apache apache 45 2010-04-14 14:08 tags.cache
-rw-rw-rw-. 1 apache apache 7 2010-04-16 15:33 undo.branch
-rw-rw-rw-. 1 apache apache 192K 2010-04-16 15:33 undo.dirstate
[root@builds .hg]# cd store
[root@builds store]# ll
total 308K
drwxrwxrwx. 4 apache apache 4.0K 2010-04-19 11:26 .
drwxrwxrwx. 3 apache apache 4.0K 2010-04-19 14:43 ..
-rw-rw-rw-. 1 apache apache 20K 2010-04-16 15:33 00changelog.i
-rw-rw-rw-. 1 apache apache 81K 2010-04-16 15:33 00manifest.i
drwxrwxrwx. 17 apache apache 4.0K 2010-04-13 11:47 data
drwxrwxrwx. 3 apache apache 4.0K 2010-04-13 11:43 dh
-rw-rw-rw-. 2 apache apache 177K 2010-04-15 11:03 fncache
-rw-rw-rw-. 1 apache apache 67 2010-04-16 15:33 undo
I have a clone of the repo elsewhere on the machine running as a different user. If I set the the default value in the [paths] section of the clones hgrc file to the local filepath on the server, the push works fine, but if I switch it to use the url, I get the error every time.
Some possible quirks in how I've set this up... hgwebdir.cgi is sitting in /var/www/cgi-bin and the repo is a child of /opt/hg. I turned off suexec as well, and this doesn't seem to clear up the issue. The only line I added in the apache config to get hgwebdir running is:
ScriptAlias /hg "/var/www/cgi-bin/hgwebdir.cgi"
The hgweb.config is also in /var/www/cgi-bin and it's contents are:
[collections]
/opt/hg = /opt/hg
[trusted]
users = *
[web]
baseurl = /hg
push_ssl = false
allow_push = *
The repo browser is working fine, it's just push that doesn't work. Apache error_log doesn't have anything in about this error at all.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
对我来说，这是服务器上的权限设置错误。 chown -R www-data /path/to/repo （在服务器上）为我修复了这一切......也许这对你来说是不同的。
祝你好运。
For me it was the permissions were set wrong on the server. A
chown -R www-data /path/to/repo(on the server) fixed it all up for me... maybe this is different for you.Good luck.
我在 Ubuntu 上也遇到了类似的问题。当我放松对
.hg目录的权限时，问题就停止了。我从 repo 目录中执行了 chmod -R 777 .hg 。之后，一切顺利。我仍然需要尝试找到允许推送的最低限度的许可选项，但这适用于我们的内部开发服务器。
I had a similar problem on Ubuntu. The problem stopped when I loosened the permissions on the
.hgdirectory.I did a
chmod -R 777 .hgfrom the repo directory. After that, everything worked. I still need to play around to find the minimally permissive option that permits pushes, but this works on our internal dev server.而不是 777，网络服务器在
apache组下运行，并且您的存储库位于/opt/hg中：执行
sudo chown :apache /opt/hg -R将存储库添加到 apache 组，并使用sudo chmod g+w /opt/hg -R授予对该组的写入权限。这样你只要给予足够的权限即可。顺便说一句，在 Ubuntu 下，apache 进程在
www-data下运行，而不是在apache下运行。Instead of 777, with the webserver running under the group
apache, and your repositories in/opt/hg:Execute
sudo chown :apache /opt/hg -Rto add the repositories to the apache group andsudo chmod g+w /opt/hg -Rto give write access to the group. This way you just give enough permissions.BTW under Ubuntu the apache process runs under
www-datainstead ofapache.在我看来，回购协议从第一次身份验证开始就被锁定，在第一次身份验证中它获取了变更集。
获得 chagesets hg 后尝试再次进行身份验证，而我想，存储库仍处于锁定状态
Hg 在失败前验证 3 次（autenticação http：usuário goolic，senha **************）
It would appear to me that the repo is locked from the first auth, in wich it gets the changesets.
After getting the chagesets hg tries to authenticate again while, i suppose, the repo is still locked
Hg autehticates 3 times before failing (autenticação http: usuário goolic, senha **************)
这是一个selinux问题。
我刚刚解决了同样的问题，
请尝试作为 root
echo 0> /selinux/enforce
并重试。这将禁用selinux直到重新启动，因此要永久修复它，您需要禁用selinux或弄清楚如何禁用这个特定问题，
这是我找到解决方案的地方
http://mercurial.808500.n3.nabble.com/Push-Denied-hg- store-lock-FC12-https-ldap-wsgi-td814854.html
selinux 禁用信息此处
http://www.crypt.gen.nz/selinux/disable_selinux.html
It is an selinux issue.
I just got through the same issue
try this as root
echo 0> /selinux/enforce
and try again. that will disable selinux until reboot so to fix it permanently you will need to disable selinux or figure out how to disable this specific issue
here is where I found the solution
http://mercurial.808500.n3.nabble.com/Push-Denied-hg-store-lock-FC12-https-ldap-wsgi-td814854.html
selinux disabling info here
http://www.crypt.gen.nz/selinux/disable_selinux.html
进入此线程试图解决类似的错误，但设置略有不同（ubuntu，存储库中的 cgi 文件）。
长话短说，我有两个主要问题：
Got to this thread trying to solve a similar error, on a slightly different setup (ubuntu, cgi file in the repositry base).
Long story short I had 2 major issues:
我遇到了与 @pete-brumm 类似的情况，但因为我稍后将过渡到受控区域，所以关闭 SELinux 不是一个选择。
像 Pete 所说的那样关闭 SELinux 并重试该操作 - 如果有效，则您已经隔离了问题。像这样重新打开它：
在完全关闭 SELinux 之前，尝试更改存储库所在的安全上下文：
I had a similar situation to @pete-brumm, but becasue I will be transitioning to a controlled region later, turning off SELinux isn't an option.
Turn SELinux off like Pete say and retry the action - if it works, you've isolated the issue. Turn it back on like this:
Before turning SELinux off completely, try changing the security context where your repos are located:
对于那些搜索这些档案的人来说，还有另一种可能性。
我正在从 apache 运行 WSGIDaemonProcess，如下所示：
所以，就我而言，拥有存储库中文件的 user:group 应该是 hgrepo:hgrepo，而且，事实上，我有这个权利。然而，果然，快速实验 chmod 0777 显示该问题在某种程度上是标准所有权/权限问题。好吧，事实证明我在 apache 配置中有另一个 WSGIDaemonProcess，完全出于不同的目的，指向不同的位置，并分配了不同的 processGroup、用户和组。然而，这个（上图）WSGIDaemonProcess 正在作为其他 user:group 运行，所以，当然，它不起作用。现在，我刚刚删除了其他过程，因为它只是实验性的，但是，fwiw，这是一个用于存档的过程。
One other possibility for those searching these archives.
I was running a WSGIDaemonProcess from apache, like so:
So, in my case, the user:group owning the files in the repo should've been hgrepo:hgrepo, and, indeed, I had this right. Yet, sure enough, a quick experimental chmod 0777 revealed that the problem was somehow a standard ownership/permissions problem. Well, it turns out that I had another WSGIDaemonProcess in the apache config, for a different purpose altogether, pointing to a different location, and assigned a different processGroup, user, and group. Nevertheless, this (above) WSGIDaemonProcess was running as that other user:group, and, so, of course, it wasn't working. For now, I've just removed that other process, as it was only experimental anyway, but, fwiw, here's one for the archives.