WSL+samba+git: "error: insufficient permission for adding an object to repository database .git/objects" / git-clone / git-add permission errors

Question

I'm working on Win10 using the WSL1 (Windows Linux Subsystem) with Ubuntu 20.04.1 LTS. I have a Samba (1.0) Network Share on which I want to create my git repository via my Ubuntu Terminal.

christian@my_pc:~/p/git_test$ ll
total 2048
drwxr-xr-x 1 christian christian  512 Jan 19 11:13 ./
drwxr-xr-x 1 christian christian  512 Jan 19 10:11 ../
-rwxr--r-- 1 christian christian    0 Jan 19 10:12 my_code_file.rb

I can git init without a problem, however, as soon as I try to git add a file, I get this error:

christian@my_pc:~/p/git_test$ git add my_code_file.rb
error: insufficient permission for adding an object to repository database .git/objects
error: my_code_file.rb: failed to insert into database
error: unable to index file 'my_code_file.rb'
fatal: adding files failed

The permissions, however, are all right, as far as I can tell. All files belong to christian:christian. The tree looks like this:

.git
├── [-rwxr--r--]  HEAD
├── [drwxr-xr-x]  branches
├── [-rwxr--r--]  config
├── [-rwxr--r--]  description
├── [drwxr-xr-x]  hooks
│   ├── [-rwxr--r--]  applypatch-msg.sample
│   ├── [-rwxr--r--]  commit-msg.sample
│   ├── [-rwxr--r--]  fsmonitor-watchman.sample
│   ├── [-rwxr--r--]  post-update.sample
│   ├── [-rwxr--r--]  pre-applypatch.sample
│   ├── [-rwxr--r--]  pre-commit.sample
│   ├── [-rwxr--r--]  pre-merge-commit.sample
│   ├── [-rwxr--r--]  pre-push.sample
│   ├── [-rwxr--r--]  pre-rebase.sample
│   ├── [-rwxr--r--]  pre-receive.sample
│   ├── [-rwxr--r--]  prepare-commit-msg.sample
│   └── [-rwxr--r--]  update.sample
├── [drwxr-xr-x]  info
│   └── [-rwxr--r--]  exclude
├── [drwxr-xr-x]  objects
│   ├── [drwxr-xr-x]  e6
│   │   └── [-r-xr--r--]  tmp_obj_mZzHwy
│   ├── [drwxr-xr-x]  info
│   └── [drwxr-xr-x]  pack
└── [drwxr-xr-x]  refs
    ├── [drwxr-xr-x]  heads
    └── [drwxr-xr-x]  tags

10 directories, 17 files

Whats strange is, that after git add my_code_file.rb I am no longer able to delete the .git dir, without permission error:

christian@my_pc:~/p/git_test$ rm -rf .git
rm: cannot remove '.git/objects/e6/tmp_obj_mZzHwy': Permission denied

It seems git creates the tmp_obj_mZzHwy without giving me permission to delete it, which shouldn't be I guess.

Here again the permissions for the .git Folder after the git add my_code_file.rb

christian@my_pc:~/p/git_test$ ls -lahR .git
.git:
total 0
drwxr-xr-x 1 christian christian 512 Jan 19 11:14 .
drwxr-xr-x 1 christian christian 512 Jan 19 11:13 ..
drwxr-xr-x 1 christian christian 512 Jan 19 11:14 objects

.git/objects:
total 0
drwxr-xr-x 1 christian christian 512 Jan 19 11:14 .
drwxr-xr-x 1 christian christian 512 Jan 19 11:14 ..
drwxr-xr-x 1 christian christian 512 Jan 19 11:13 e6

.git/objects/e6:
total 1.0M
drwxr-xr-x 1 christian christian 512 Jan 19 11:13 .
drwxr-xr-x 1 christian christian 512 Jan 19 11:14 ..
-r-xr--r-- 1 christian christian   0 Jan 19 11:13 tmp_obj_mZzHwy

The Samba Share on which I am working is mounted as drive (with letter P:) on Win10. On my WSL Ubuntu I mount it via /etc/fstab with following line:

P:▸ /mnt/p▸ drvfs▸defaults,metadata,rw,exec,uid=christian,gid=christian,umask=22,fmask=11▸0 0

My .git/config for the repo

[core]
        repositoryformatversion = 0
        filemode = false
        bare = false
        logallrefupdates = true
        symlinks = false
        ignorecase = true

What I already tried to fix the problem:

• chmod -R u+rwx .
• git init --shared=all
• umask 0000

On my home dir (resp. non-samba drive) git init/add works without problems.

---

Update

I found out that the samba share is not mounted properly, the metadata option is missing resp. gets ignored whenever I mount it. I think this might be the problem! However, its not clear to me, why it's ignored or if there is a way to force it?

TARGET                       SOURCE      FSTYPE      OPTIONS
/                            rootfs      wslfs       rw,noatime
...
├─/mnt/p                     P:          drvfs       rw,noatime,uid=1000,gid=1000,case=off
└─/mnt/c                     C:\         drvfs       rw,noatime,uid=1000,gid=1000,metadata,case=off

Answer 1

In addition of WSL2, you might still encounter another error because of the built-in File System Monitor included with recent Git.

With Git 2.38 (Q3 2022), the built-in fsmonitor refuses to work on a network mounted repositories; a configuration knob for users to override this has been introduced.

See commit 85dc0da (11 Aug 2022) by Eric DeCosta (edecosta-mw).
^{(Merged by Junio C Hamano -- gitster -- in commit 0479138, 13 Sep 2022)}

fsmonitor: option to allow fsmonitor to run against network-mounted repos

^{Signed-off-by: Eric DeCosta}

Though perhaps not common, there are use cases where users have large, network-mounted repos.
Having the ability to run fsmonitor against network paths would benefit those users.

Most modern Samba-based filers have the necessary support to enable fsmonitor on network-mounted repos.
As a first step towards enabling fsmonitor to work against network-mounted repos, introduce a configuration option, 'fsmonitor.allowRemote'.
Setting this option to true will override the default behavior (erroring-out) when a network-mounted repo is detected by fsmonitor.

---

This comes from With Git 2.37 (Q2 2022), which clarifies the incompatibility with network drives:

See commit 3294ca6, commit 53fcfbc, commit eb29901, commit 00991e1, commit 9915e08, commit d6d58ff, commit caa9c37, commit f954c7b, commit 7667f9d, commit b533708, commit 95a4e78, commit de7e0b5, commit 6504cfd, commit 90a70fa, commit d060555, commit 207534e, commit 802aa31, commit 39664e9, commit 8e8f4b8, commit 9968ed7, commit ddc5dac, commit d989b26, commit 1e7be10, commit a85ad67, commit 5c58fbd, commit d33c804, commit 62a62a2, commit 49b398a, commit 27b5d41, commit 40f865d (26 May 2022) by Jeff Hostetler (Jeff-Hostetler).
See commit 852e2c8 (25 Mar 2022) by Junio C Hamano (gitster).
^{(Merged by Junio C Hamano -- gitster -- in commit 9e496ff, 10 Jun 2022)}

fsmonitor-settings: NTFS and FAT32 on MacOS are incompatible

^{Signed-off-by: Jeff Hostetler}

On MacOS mark repos on NTFS or FAT32 volumes as incompatible.

The builtin FSMonitor used Unix domain sockets on MacOS for IPC with clients.
These sockets are kept in the .git directory.
Unix sockets are not supported by NTFS and FAT32, so the daemon cannot start up.

Test for this during our compatibility checking so that client commands do not keep trying to start the daemon.

The full comment:

Remote working directories are problematic for FSMonitor.

The underlying file system on the server machine and/or the remote mount type (NFS, SAMBA, etc.) dictates whether notification events are available at all to remote client machines.

Kernel differences between the server and client machines also dictate the how (buffering, frequency, de-dup) the events are delivered to client machine processes.

A client machine (such as a laptop) may choose to suspend/resume and it is unclear (without lots of testing) whether the watcher can resync after a resume.
We might be able to treat this as a normal "events were dropped by the kernel" event and do our normal "flush and resync" --or-- we might need to close the existing (zombie?) notification fd and create a new one.

In theory, the above issues need to be addressed whether we are using the Hook or IPC API.

For the builtin FSMonitor, we create the Unix domain socket for the IPC in the .git directory.

If the working directory is remote, then the socket will be created on the remote file system.
This can fail if the remote file system does not support UDS file types (e.g. smbfs to a Windows server) or if the remote kernel does not allow a non-local process to bind() the socket.
(These problems could be fixed by moving the UDS out of the .git directory and to a well-known local directory on the client machine, but care should be taken to ensure that $HOME is actually local and not a managed file share).

So (for now at least), mark remote working directories as incompatible.

FAT32 and NTFS working directories are problematic too.

The builtin FSMonitor uses a Unix domain socket in the .git directory for IPC.
These Windows drive formats do not support Unix domain sockets, so mark them as incompatible for the daemon.

---

With Git 2.39 (Q4 2022), by default, use of fsmonitor on a repository on networked filesystem is disabled.
Add knobs to make it workable on macOS.

See commit c4f9490 (10 Oct 2022) by Jeff King (peff).
See commit 5aa9e32, commit 25c2cab, commit 12fd27d, commit 8f44976, commit 6beb268, commit 508c1a5 (04 Oct 2022) by Eric DeCosta (edecosta-mw).
^{(Merged by Junio C Hamano -- gitster -- in commit 7b8cfe3, 17 Oct 2022)}

fsmonitor: add documentation for allowRemote and socketDir options

^{Signed-off-by: Eric DeCosta}

Add documentation for 'fsmonitor.allowRemote' and 'fsmonitor.socketDir'.
Call-out experimental nature of 'fsmonitor.allowRemote' and limited filesystem support for 'fsmonitor.socketDir'.

git config now includes in its man page:

fsmonitor.allowRemote

By default, the fsmonitor daemon refuses to work against network-mounted repositories. Setting fsmonitor.allowRemote to true overrides this behavior. Only respected when core.fsmonitor is set to true.

git fsmonitor--daemon now includes in its man page:

By default, the fsmonitor daemon refuses to work against network-mounted repositories; this may be overridden by setting fsmonitor.allowRemote to true. Note, however, that the fsmonitor daemon is not guaranteed to work correctly with all network-mounted repositories and such use is considered experimental.

---

And Git 2.39 (Q4 2022) fixes an issue where core.fsmonitor on macOS would not notice created or modified symbolic links.

See commit ee0e7fc (08 Nov 2022) by srz_zumix (srz-zumix).
^{(Merged by Junio C Hamano -- gitster -- in commit 8d7b35b, 23 Nov 2022)}

fsmonitor--daemon: on macOS support symlink

^{Signed-off-by: srz_zumix
Signed-off-by: Taylor Blau}

Resolves a problem where symbolic links were not showing up in diff when created or modified.

kFSEventStreamEventFlagItemIsSymlink is also treated as a file update.
This is because kFSEventStreamEventFlagItemIsFile is not included in FSEvents when creating or deleting symbolic links.
For example:

$ ln -snf t test
    fsevent: '/path/to/dir/test', flags=0x40100 ItemCreated|ItemIsSymlink|
$ ln -snf ci test
    fsevent: '/path/to/dir/test', flags=0x40200 ItemIsSymlink|ItemRemoved|
    fsevent: '/path/to/dir/test', flags=0x40100 ItemCreated|ItemIsSymlink|

Answer 2

Solution: Upgrade to WSL2

As I found out, the solution was to Upgrade from WSL1 to WSL2, there mounting works correctly. I'm able to git-add or git-clone without permission errors now.

Open a PowerShell to see your current version:

PS C:\Users\christian> wsl -l -v
  NAME      STATE           VERSION
* Ubuntu    Stopped         1

In case its 1 you can upgrade it, but check the WSL2 requirements first (just to be safe).

Upgrade Guide

Excerpt from Guide/Steps I had to do:

• Check WSL2 Requirements Windows above certain build resp. meets the requirements
• Download and execute: WSL2 Linux kernel update package for x64 machines
• Enable Windows Virtual Machine Platform Feature: dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
• Reboot
• Upgrade your distro to WSL2: open Powershell and enter wsl --set-version <distribution name> <versionNumber>, in my case it was wsl --set-version Ubuntu 2. To see your distribution name type wsl -l -v
• Verify the upgrade with wsl -l -v

Just to provide complete information, here also the mount options /etc/fstab

P:      /mnt/p  drvfs   rw,noatime,uid=christian,gid=christian,metadata,case=off        0 0

Compared to

christian@my_pc:~$ findmnts
...
├─/mnt/p                        P:           9p          rw,noatime,dirsync,aname=drvfs;path=P:;uid=1000;gid=1000;metadata;case=off;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=3,wfd=3
└─/mnt/c                        C:\          9p          rw,noatime,dirsync,aname=drvfs;path=C:\;uid=1000;gid=1000;uid=1000;gid=1000;metadata;case=off;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=8,wfd=8