Using a network drive as git repository

Question

So, I've created a git repository on the networked drive:

git init --bare --shared

and that works fine. Then, I clone it to a local drive with

git clone z:/testgit

and that also works fine. Then I add a file, stage, and commit

git stage *
git commit -m "test commit"

and that ALSO works fine. BUT! When I try to push to the origin, I get this error.

git push origin
Counting objects: 3, done.
Writing objects: 100% (3/3), 225 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: error: unable to write sha1 filename ./objects/f3/e6e90a7465421306fae05c18153260973542e3: Permission denied
remote: fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To z:/testgit14
 ! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 'z:/testgit'

When attempting to use git stage * directly on the server (on a non --bare git project) I get similar errors.

I have full access to the drive in file explorer, and even able to initialize the repository with git. SSH shouldn't even apply here since it's not a server, it's a networked drive. Everything I've read about git says that this should work. I've read dozens of "how to's" that all say these exact steps, but no one complaining about permission denied, UNLESS they're talking about SSH public keys missing on servers (which, as I've said, shouldn't apply).

What permissions am I missing? Where should I look for and set the proper permissions?

Answer 1

What happens when you try to create the file that git is complaining about?

echo test > ./objects/f3/e6e90a7465421306fae05c18153260973542e3

It's possible that git is creating a new folder (f3) and the folder is not getting the correct permissions, either due to ACL inheritance misconfiguration or because the local machine is trying to adjust the permissions on newly created folders and getting it wrong.

If it were Linux, it could be because the network drive was connected with the wrong mount options, or the umask was set incorrectly, but I'm not sure whether those are available to be changed on a Windows machine.