Errors when running "Git Bash" until it's run as administrator

[kraai]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options
git version 2.16.1.windows.1
cpu: x86_64
built from commit: 1a4ee4d5d83bbba63f6d8b71c427f627769f3386
sizeof-long: 4

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.15063]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: VIM
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

Not that I can think of.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash.

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

1. Install or upgrade Git for Windows.
2. Run Git Bash.

• What did you expect to occur after running these commands?

I expected no errors to be displayed before the first prompt.

• What actually happened instead?

The following errors were displayed before the first prompt:

mkdir: cannot create directory '/dev/shm': Read-only file system

Creating /dev/shm directory failed.
POSIX semaphores and POSIX shared memory will not work

mkdir: cannot create directory '/dev/mqueue': Read-only file system

Creating /dev/mqueue directory failed.
POSIX message queues will not work

ln: failed to create symbolic link '/dev/stdin': Read-only file system
ln: failed to create symbolic link '/dev/stdout': Read-only file system
ln: failed to create symbolic link '/dev/stderr': Read-only file system
ln: failed to create symbolic link '/dev/fd': Read-only file system
ln: failed to create symbolic link '/etc/mtab': Permission denied
'C:\windows\system32\drivers\etc\hosts' -> '/etc/hosts'
/usr/bin/cp: cannot create regular file '/etc/hosts': Permission denied
'C:\windows\system32\drivers\etc\protocol' -> '/etc/protocols'
/usr/bin/cp: cannot create regular file '/etc/protocols': Permission denied
'C:\windows\system32\drivers\etc\services' -> '/etc/services'
/usr/bin/cp: cannot create regular file '/etc/services': Permission denied
'C:\windows\system32\drivers\etc\networks' -> '/etc/networks'
/usr/bin/cp: cannot create regular file '/etc/networks': Permission denied
rm: cannot remove '/etc/post-install/01-devices.post': Permission denied
rm: cannot remove '/etc/post-install/03-mtab.post': Permission denied
rm: cannot remove '/etc/post-install/06-windows-files.post': Permission denied
rm: cannot remove '/etc/post-install/99-post-install-cleanup.post': Permission denied

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

The problem does not occur with a specific repository.

---

I found these errors mentioned in #1326, but that issue appears to be related to creating an installer, not with a problem with the official installer. I wasn't able to find post-install.log anywhere on my system. %TEMP% did not contain any subdirectory starting with "is".

[dscho]

These file operations should have been performed as part of the installation, as last step. Did you see the installer "hang"?

[kraai]

No, the installer did not appear to hang. Once I answered all of the pre-install questions, it displayed a progress bar while extracting files, etc., and then displayed the final page which gave me the option to run Git Bash and/or display the release notes.

[dscho]

@kraai does this happen even after reinstalling? If so, could you reinstall using the installer option /LOG=<path> and see whether you find the part about the post-install script?

[kraai]

@dscho Yes, it happens after reinstalling. I've reinstalled using the installer option /LOG=<path>. Here is the resulting log file:

log.txt

I can see where it installs post-install.bat, but I don't see any other references to that file name.

[dscho]

Right. The post-install.bat should have run, but I don't think it logs anything in case of success. So I tried to get it to output a bit more information. Would you mind testing the installer I just uploaded to https://github.com/dscho/build-extra/releases/tag/v2.16.1-post-install-test?

[kraai]

@dscho No problem. I ran the v2.16.1-post-install-test installer. Here is the log it generated:

log-1.txt

I think this is the relevant section:

2018-02-01 07:14:12.184   Line 2113: Executing C:\Program Files\Git\post-install.bat
2018-02-01 07:14:13.666   Line 2121: post-install scripts run successfully:
                          "running post-install"

                          Creating /dev/shm directory failed.
                          POSIX semaphores and POSIX shared memory will not work


                          Creating /dev/mqueue directory failed.
                          POSIX message queues will not work

                          'C:\windows\system32\drivers\etc\hosts' -> '/etc/hosts'
                          'C:\windows\system32\drivers\etc\protocol' -> '/etc/protocols'
                          'C:\windows\system32\drivers\etc\services' -> '/etc/services'
                          'C:\windows\system32\drivers\etc\networks' -> '/etc/networks'
                          C:\Program Files\Git\post-install.bat

2018-02-01 07:14:13.815   Need to restart Windows? No

[dscho]

Yes, this is the relevant section. It also shows that Creating /dev/shm failed, but you claimed earlier that it worked when you ran Git Bash as administrator?

This is the relevant part in /etc/post-install/01-devices.post for the /dev/shm directory:

  # Create it if necessary
  if [ ! -e "${DEVDIR}/shm" ]
  then
    mkdir -m 1777 "${DEVDIR}/shm"
    if [ ! -e "${DEVDIR}/shm" ]
    then
      echo
      echo "Creating ${DEVDIR}/shm directory failed."
      echo "POSIX semaphores and POSIX shared memory will not work"
      echo
    fi
  else
    chmod 1777 "${DEVDIR}/shm"
  fi

As you can see, it fails to create the directory for the POSIX semaphores (not sure what uses it, but I could imagine that our OpenSSH as well as our Perl does).

So I think that a valid work-around would be to teach the installer to create that directory already... as well as the mqueue directory.

Are you up for some fun and easy contribution to the Git for Windows project?

[kraai]

@dscho I'm having trouble installing the SDK. Once I get it installed, I'll try to fix this issue.

[dscho]

@kraai I think the SDK does not currently work as expected, mostly because BinTray (which we use to host our Pacman packages, a decision I dearly regret now) has blocked services "due to overuse".

In the mean-time, you may get unblocked by using https://github.com/git-for-windows/git-sdk-64. I did not get around to define the .gitattributes correctly yet, so it is a little involved:

• C:
• cd \
• git init git-sdk-64
• cd git-sdk-64
• git config core.autocrlf false
• git remote add -f origin https://github.com/git-for-windows/git-sdk-64
• git reset --hard origin/master

You will also want to check out build-extra, of course:

• cd \git-sdk-64
• mkdir usr
• mkdir src
• git init usr\src\build-extra
• cd usr\src\build-extra
• git config core.autocrlf false
• git remote add -f origin https://github.com/git-for-windows/build-extra
• git reset --hard origin/master

You can then start the Git SDK Bash using C:\git-sdk-64\git-bash.exe.

[kraai]

@dscho I was able to install the SDK and modify the installer so that it created /dev, /dev/shm, and /dev/mqueue before running post-install.bat. It still displayed the following errors until I ran Git Bash as an administrator, though:

rm: cannot remove '/etc/post-install/01-devices.post': Permission denied
rm: cannot remove '/etc/post-install/03-mtab.post': Permission denied
rm: cannot remove '/etc/post-install/06-windows-files.post': Permission denied
rm: cannot remove '/etc/post-install/99-post-install-cleanup.post': Permission denied

I discovered that was able to eliminate all of these errors by running the official release's installer with elevated privileges.

I'm not sure what to do.

[dscho]

I discovered that was able to eliminate all of these errors by running the official release's installer with elevated privileges.

So your installer does not elevate automatically? I.e. you do not get that prompt where you are asked whether you are sure you want to run this .exe as administrator?

[kraai]

@dscho When I double-click on the installer in Windows Explorer, it displays the following dialog:

Once I select a reason and enter my password, the installer runs and the error messages appear when I run Git Bash.

If I right-click on the installer in Windows Explorer and select "Run with Elevated Privileges", it displays a similar dialog, but once I finish the installation, Git Bash doesn't display the errors.

I think this dialog is coming from Avecto Defendpoint.

[dscho]

I think this dialog is coming from Avecto Defendpoint.

Hmm. That's too bad. Apparently, there is something going on where this software allows sort of a "kind of elevated" operation?

The best idea I could come up: teach the installer to detect that the post-install script did not, in fact, create, say, the mqueue directory, and tell the user that something funky is going on and they need to run Git Bash as administrator once.

What do you think?

[tajmone]

I've experienced a very similar problem today after updating Git to version 2.24.0.windows.2 via Chocolatey.

After the update I would get 4 erros messages on opening Bash, all of them regarding the impossibility to delete some .post files inside etc/post-install/. Re-installing Git via Chocolatey didn't solve the problem, but deleting those files manually from File Explorer did.

In many years of running Git on Win10 via Chocolatey this was the first time I experienced the problem. Luckily, it was easy to solve.

[dscho]

Re-installing Git via Chocolatey didn't solve the problem, but deleting those files manually from File Explorer did.

Any idea why those files could not be deleted? Maybe an overzealous malware scanning them?

[tajmone]

Any idea why those files could not be deleted?

Unfortunately, I hadn't expanded the log in Chocolatey GUI during the installation, and closed the app after, so I didn't have a change to get the details.

Maybe an overzealous malware scanning them?

I only use Win 10's native defender; but since they were very small script files I doubt it would be due to long scanning times.

One thing I did notice is that there was an update to the Chocolatey Core package, which I carried out after the Git update, although it would have been better to do that one first. But even after the Choco core update trying to reinstall Git for Windows didn't solve the problem.

I think that it has something to do with Chocolatey, for it run with admin privileges and this could be the reason why the files couldn't be deleted automatically by Bash at startup.

As I said, in many years it only happened once, and since the error reported by Bash was exhaustive it was easy to fix. Still, it would be good to know why this happens from time to time.

If it happens again I'll try to keep a detailed log and post it here.

[tajmone]

The problem showed again after updating to git version 2.24.1.windows.2 (via Chocolatey):

rm: cannot remove '/etc/post-install/01-devices.post': Permission denied
rm: cannot remove '/etc/post-install/03-mtab.post': Permission denied
rm: cannot remove '/etc/post-install/06-windows-files.post': Permission denied
rm: cannot remove '/etc/post-install/99-post-install-cleanup.post': Permission denied

Again, nothing serious, just had to manually delete contents of the C:\Program Files\Git\etc\post-install\ folder, but the problem is there. I wonder if this is a symptom of something that could lead to problems — whether it's a problem on Chocolatey side or Git not having full control over its operations due to messed up privileges.

Do you think that this could lead to problems in Git workings?

I've no idea why this creeped in at some point (being using the same Git package for ages, just updating it).

Any other users experiencing this?

[dscho]

@tajmone those files should have been removed as part of the silent install that Chocolatey performs... Strange that they have not been removed...

[tajmone]

Any suggestions to pin point the cause and remove the problem?

[dscho]

@tajmone I have seen a few reports of the initial Bash run (that is part of the installation) hanging and failing to complete, but there is hardly any useful breadcrumb as to the underlying reason, let alone anything conclusive.

[tajmone]

If the problem boils down to having do delete these files manually, then it's no big deal (also, it doesn't happen at very update, only sometimes, which is weird).

My only worry is if there's an underlying wrong-permissions issue that might affect other aspects of Git functionality on Windows. So far I didn't encounter any, but I work mostly with a proprietary Git GUI, and use the Bash version only for certain file and repo info operations.

[hmccsGitHub]

FYI: Had same problem while launching the "Git Bash" from the Windows 10 Start Menu icon; opens in home directory. Came to this post looking for answers. Somehow cleared the issue while trying various workarounds.

• Start menu shortcut starts the Bash shell at the "home"/"~" folder.
• Was getting the same errors as described at first post.
• Launching an admin version of the shell via right/context click from the running task bar item showed no warnings/errors.
• Reviewing this post...
• Tried reinstalling Git using chocolatey; @2.24.1.2; problem still there w/ Start menu shortcut. Tried reinstalling multiple times to try to confirm whether install was being performed in an elevated context using Task Manager/Resource Manager; too quick (chocolatey is running admin elevated though)
• Tried launching the bash shell from a targeted folder using the Windows Explorer UI's right-click/context-menu; No warnings/errors and not running elevated.
• The kicker: The Start shortcut now launches clean as well.

With my environment now fixed I can not repeat the process, and not 100% sure if running the Explorer launch of the bash shell is what allowed for completion of needed tasks that are generating the warnings/errors being discussed here. Perhaps someone can more carefully try to reproduce this result?

1. Confirm Start Menu shortcut as issue. Exit shell after fail.
2. Launch the Windows Explorer context menu on a folder (perhaps the "~"/"home" folder, which is where the Start menu version starts at?).
3. Confirm problem does goes away. Exit shell
4. Launch the Start menu shortcut again - have the warning/errors go away? Are the /dev/shm and /dev/mqueue present?

This fix would imply some differences in the Start Menu shortcut versus Explorer shell menu shortcut that is thwarting the proper post install script execution. Once the task completes successfully fixes it everywhere?

[sur5r]

This was still present for me in 2.26.2, updating to 2.27.0 (via choco GUI) did not change it.

The mentioned workaround did.

Uninstalling and reinstalling 2.27.0 did not reintroduce the issue despite e.g. %PROGRAMFILES%\Git\dev\shm being removed after uninstall.

Is it possible new installs don't suffer from this?

Update: I just installed 2.27.0 via Choco GUI on an otherwise fresh Win10 installation and did not encounter the issue.

[tajmone]

Interesting observations @hmccsGitHub, thanks for the tips.

I was experiencing this problem through a custom invocation of Bash from an alternative tool to FIle Explorer (Altap Salamander, similar to Total Commander), which invokes the Bash at the current folder.

I must try your fix. I was convinced it had to do with the permissions settings of the folder containing the temp files to be deleted (because when I try to fix this problem, after each update, I always get asked for elevated confirmation).

I hope all these feedback can help pin-point the problem, so that both current user of this package can see it solved as well as new installers not having to face it.

[dscho]

Is it possible new installs don't suffer from this?

Totally possible. It could be a left-over C:\Program Files\Git\dev\stdin or something, one that is not in the expected format so that the installer tries to create it and that somehow fails...

[tajmone]

Update on @hmccsGitHub's solution — after my previous Chocolatey update for Git I tried the solution proposed by @hmccsGitHub, which worked ... until the next Git update! after updating, the problem came back again: when opening Bash, it can't delete the temporary files.

So it seems that the error is persistent, and that it has to do with folders permissions which are preventing the deletion of those temporary files.

So, right now, the only quick way to fix the problem after each update seems to be opening the Bash with admin privileges once, which allows the deletion of the temp files — but this is a bit of nagger, and it would be nice to find a way to solve the problem once and for all for those who find themselves in this situation.

Maybe a PowerShell script that fixes the permissions on these folders?

I personally don't like to fiddle with folders permissions (especially since the Windows preferences to handle them are packed with options and sub-dialogues, which make it easy to mess up things badly), so I'd feel better if there was an officially endorsed script to fix the problem.

I still wonder how the problem came into being, and how many users might be affected by this.

Also, would it be possible to delete the culprit folders to solve the problem? i.e. hoping that Git will recreate them, this time using the right permissions (unless Chocolatey is causing the permissions problem due to its process being executed with admin privileges).

[amankumar6]

I was also getting this error so, I uninstalled Git and re-installed it and it fixed the problem. Try if that's works for you.

[dscho]

Closing this as stale.