This can cause issue if the source repository has been created under Gitolite2 and the Tuleap instance is now running Gitolite3, Gitolite configuration will not be updated until a new Git repo is created in the project (meaning users will not be able to access the forked repo). In this case, the FORK_REPO system event is in error with this kind of traces (sorry for the french in the logs...):

Command execution failure: cd /var/lib/tuleap/gitolite/repositories; sg - gitolite -c "cp -f /var/lib/tuleap/gitolite/repositories/project1/test_gitolite.git/hooks/* /var/lib/tuleap/gitolite/repositories/project1/u/user1/test_gitolite.git/hooks/" 2>&1 (return value: 1):
cp: impossible d'évaluer « /var/lib/tuleap/gitolite/repositories/project1/test_gitolite.git/hooks/gl-pre-git.hub-sample »: Aucun fichier ou dossier de ce type
cp: impossible d'évaluer « /var/lib/tuleap/gitolite/repositories/project1/test_gitolite.git/hooks/post-receive »: Permission non accordée
cp: impossible d'évaluer « /var/lib/tuleap/gitolite/repositories/project1/test_gitolite.git/hooks/update »: Permission non accordée


Also, it appears than in some undefined cases the filesystem permission applied to the forked repo are wrong which leads to this kind of errors client side when the user try to push new content:

remote: error: insufficient permission for adding an object to repository database ./objects
remote: fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit


The fork process must be made more resilient.