Note that there are some explanatory texts on larger screens.

plurals
  1. POWhy does Mercurial return "Abort: Access is Denied" when trying to push a repository?
    primarykey
    data
    text
    <p>I'm running into a problem with a user not being able to push his commits into a Mercurial repository and am perplexed as to why it's not working for him. I've tried several things to figure out what's up, Googling doesn't turn up anything helpful... so here I am.</p> <p>First, the configuration. We have a Windows XP SP2 x64 machine on our network acting as our official repository server. This contains several repositories on it. We clone / push / pull using a folder on that drive that is shared. Permissions are given to everyone for read access. Users that can push (including the user that has problems), are given full control. The user's machine is Win XP based. My machine (used to help troubleshoot things) is also Win XP based.</p> <p>Second, the symptoms. The user is using TortoiseHg 2.1.1 to do his work. He can clone just fine, commits to his local repo are a-o-k, etc. When he tries to push, however, TortoiseHg returns a "abort, ret 255" code. Not very helpful. So, we've gone to the command line and have issued "hg push -v --debug". Here it returns "abort: Access is Denied". This same user can write to the server's shared folder no problem -- he can create files, directories and delete the same as well. So, reading / writing access the drive / folder is not an issue.</p> <p>Third, our experimentation results. Here are some weird results from testing. The user created a new, local test repo. I logged into the server machine and created a test repo for him to push to. The user checked in a file and then pushed it up to the test repo on the server machine. This worked fine. No aborts. Life was good. He was able to do a few more pushes and it continued to work as expected. I then cloned the repo to my machine, updated a file, and pushed it back out. After the user then pulled in my changes and tried to push back to the server, he once again encountered the dreaded "Access is Denied" message. Meanwhile, I can still update the project without any problems.</p> <p>As another experiment, we had the user log out and another user log in. They did so and were able to push to the server repo without a problem. Original user logs back in, makes some changes, etc. and once again hits the brick wall of "Access is Denied".</p> <p>As far as we can tell, the problem is not related to Windows credentials. Otherwise, we'd expect that creating arbitrary files on the server's shared folder would not work. Further, until I made an update to the test repo the user created, he could push to that particular repo just fine.</p> <p>Any ideas? What additional credential checks is Mercurial making that might cause this?</p> <p><strong>UPDATE:</strong></p> <p>After a tip from Wim, I started to look at the permissions on the various objects of the repo using 'cacls'. This is a Windows tool that "displays or modifies access control lists of files". I had the user create a new repo and then took a snapshot of the permissions. I then checked in a file to the same repo and took another snapshot of the changes. </p> <p>It turns out that there are several repo file permissions that get updated as a result of this: undo.bookmarks, undo.branch, undo.desc, undo.dirstate, branchheads, 00changelog.i, 00manifest.i, undo, and the single file of the repository. All of these files had permissions similar to the following:</p> <pre><code>C:\Projects\Mercurial\hgtest4\.hg\store\undo BUILTIN\Administrators:F NT AUTHORITY\SYSTEM:F DOMAINxxxx\USERIDxxxx:F BUILTIN\Users:R </code></pre> <p>(actual DOMAINxxxx and USERIDxxxx values have been altered). Prior to my check-in, DOMAINxxxx &amp; USERIDxxxx reflected the user's domain and userid. After my check-in, these got updated to mine (we're on the same domain, but the userid is obviously different.) I was able to check things in and out even though <em>my</em> userid wasn't listed because I'm a member of the BUILTIN\Administrators group. The user with the problem is not. So, I'm guessing that after I checked things in, the system no longer saw him as a credentialed user with write-access (BUILTIN\User:R indicates Read-only access) and therefore caused the access denial.</p> <p>I've got a terribly Q&amp;D fix in place right now (user is now part of the Admin group...) The real fix is going to be to get the repo off of Windows Sharing and on to a proper server configuration.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload