I got some Mercurial repositories which are served by Apache over HTTP. But there is a dedicated user performing some automated tests, which needs to check out the repositories locally. Recently this started to fail, seemingly due to lacking rights for files in the largefiles subdirectory in .hg:

-rw------- 2 www-data www-data 6.3M 2012-01-02 17:23 9358b828fb64feb37d3599a8735320687fa8a3b2

Default umask should be 022. And I used the setgid settings for the directories in .hg according to the multiple committers wiki page, which does not cover .hg/largefiles though. However, as far as I understand it, setting the gid for this directory wouldn't solve the problem, that hg sets such restrictive rights on those files. My other user trying to access this repositories via the filesystem is also in the www-data group, thus an additional read right for group would be sufficient to solve my problem.

How can I convince Mercurial, or the system to grant this right properly for new files?

I am using: Mercurial Distributed SCM (version 2.1)

2 Answers 2


It turns out that this is a problem in Mercurial and that there isn't an easy work-around for Mercurial 2.1. I've just sent three patches to the Mercurial mailinglist to fix this — hopefully you'll see the fix in Mercurial 2.1.1 in a week.

The problem is that the largefiles extension is creating the .hg/largefiles/<hash> files by writing data into a temporary file which is then later renamed to the real name. It creates its temporary files using the standard tempfile module in Python. The module restricts the permissions to 600 since you normally don't want anybody to read your temporary files. The largefiles extension didn't take this into account and just renamed the file.

My patches fix this by taking the permissions of .hg/store into account when creating the temporary files. This should bring largefiles into line with the rest of Mercurial.

  • Hey, thanks a lot for having a look into this and coming up with a fix ;)
    – haraldkl
    Feb 23, 2012 at 19:31
  • @haraldkl: No problem, it was an interesting problem. The patches have been queued by Matt, so you should see them in the patch release in a week! Feb 24, 2012 at 6:49

I don't know if there's a Mercurial answer, but here's a generic answer, which may or may not work depending on exactly how Mercurial chooses file permissions.

Enable access control lists (ACLs) on the filesystem. (See this answer for instructions.) Then set the default ACL and the current ACL for the working copy to allow access to the additional user or group that requires access.

setfacl -R -d -m group:www-data:rwx /path/to/working/copy
setfacl -R -m group:www-data:rwx /path/to/working/copy
  • Thanks a lot! I actually found this answer with the setfacl already, however right now I do not have ACLs activated on that system and would rather opt for a solution which would work without them.
    – haraldkl
    Feb 17, 2012 at 17:50
  • I'm trying this exact method, the default g:www-data:r-x is set /path/to/repo and /path/to/repo/.hg However if I do an hg pull on the server, sometimes the files in /path/to/repo/.hg/store do not get created with default permissions and fail to be read by apache for other users. They're not large files, and I have to continuously do setfacl -Rm g:www-data:r-x /path/to/repo. Any ideas why this happens?
    – Budric
    Jun 5, 2012 at 14:28
  • @Budric Not offhand. It might have something to do with how hg operates. Please ask a new question. Give as much detail as you can (ideally, show how to reproduce this issue from hg init onwards). Jun 5, 2012 at 18:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .