> Since this is now seeming so fragile -- after working for about a decade,
> it's broken twice in a matter of months -- I'm questioning whether it's
> worth trying to keep the feature working. --[[Joey]]
+
+>> Of course, that's got to be your call. I haven't made a great deal of use
+>> of it, but it *does* seem more convenient if one is working on an IkiWiki
+>> patch, as I can write the website notes about it in the same tree (although
+>> I then have to cherry-pick to push that to the live site, of course.). If
+>> you decide to drop it from `ikiwiki.info`, would you leave the code as-is,
+>> or drop it as broken? Any further clues what went wrong this time?
+>> *—[[Jon]], 2021-01-13*
+
+----
+
+The HEAD.lock permissions error does not come from the post-receive hook or
+from ikiwiki when it runs it. Instead, stracing git-daemon shows that it
+happens after ikiwiki has checked the push and accepted it, and exited
+successfully.
+
+So the problem is that git-daemon is unable to write to the git repo.
+
+ drwxr-sr-x+ 8 b-git-annex b-git-annex 4096 Mar 29 17:07 /home/b-git-annex/source.git/
+
+ikiwiki-hosting's ikisite is supposed to arrange for git-daemon
+to be able to write there by using an ACL, so something about that
+must be what is broken now. --[[Joey]]
+
+Ok, found the problem. ikisite runs setfacl, and that does the right thing.
+Then ikisite runs chmod on the source.git directory (to make it suid as seen
+above). That seems to mess up the ACLs that were set earlier.
+
+The diff from good to bad ACLs, as shown by getfacl is:
+
+ -group::rwx
+ -group:ikiwiki-anon:rwx
+ -group:b-ikiwiki:rwx
+ -group:b-git-annex:rwx
+ -mask::rwx
+ +group::rwx #effective:r-x
+ +group:ikiwiki-anon:rwx #effective:r-x
+ +group:b-ikiwiki:rwx #effective:r-x
+ +group:b-git-annex:rwx #effective:r-x
+ +mask::r-x
+
+I don't understand ACLs or how a chmod could clear them but ok, ikisite needs
+to chmod before setting the ACLS.
+
+This is not an ikiwiki bug and I'll fix it in ikisite-hosting then. [[done]]
+--[[Joey]]