Git Bash shell fails to create symbolic links

Asked 5/9, 2013 at 16:50 Answered 27/6, 2023 at 1:41

112

When I try to create a symbolic link from the Git Bash shell, it fails every time all the time:

ln -s /c/Users/bzisad0/Work testlink

Output:

ln: creating symbolic link `testlink' to `/c/Users/bzisad0/Work': Permission denied

The only thing it does, besides giving the error message, is create an empty directory named (in this case) testlink.

I don't see any problem with the ln executable. For instance, it is owned by me and marked as executable:

which ln
ls -hal /bin/ln

Output:

/bin/ln

-rwxr-xr-x    1 BZISAD0  Administ      71k Sep  5 11:55 /bin/ln

I also own the current directory (~, which is /c/Users/bzisad0):

ls -dhal .

Output:

drwxr-xr-x  115 BZISAD0  Administ      40k Sep  5 12:23 .

I have administrative rights, and I've tried opening the Git Bash shell with "Run as Administrator", but that makes no difference.

I've tried opening the Windows properties for ln.exe and setting the Privilege Level to "Run this program as an administrator" but that doesn't help.

I've gone into the Security → Advanced properties in Windows and made myself (rather than the Administrators group) the owner, but that doesn't fix anything either.

I'm at a loss. I don't know whether this error message is ultimately coming from ln, from Bash, or from Windows, or how I could possibly lack the permission. How can I get to the bottom of this?

Larrabee answered 5/9, 2013 at 16:50 Comment(0)

It is possible, albeit extremely awkward, to create a symbolic link in MSysGit.

First, we need to make sure we are on Windows. Here's an example function to check that:

windows() { [[ -n "$WINDIR" ]]; }

Now, we can't do cmd /C, because MSysGit will fornicate with this argument and turn it into C:. Also, don't be tempted to use /K; it only works if you don't have a K: drive.

So while it will replace this value on program arguments, it won't on heredocs. We can use this to our advantage:

if windows; then
    cmd <<< "mklink /D \"${link%/}\" \"${target%/}\"" > /dev/null
else
    ln -s "$target" "$link"
fi

Also: note that I included /D because I'm interested in directory symlinks only; Windows has that distinction. With plenty of effort, you could write a ln() { ... } function that wraps the Windows API and serves as a complete drop-in solution, but that's... left as an exercise for the reader.

As a thank-you for the accepted answer, here's a more comprehensive function.

# We still need this.
windows() { [[ -n "$WINDIR" ]]; }

# Cross-platform symlink function. With one parameter, it will check
# whether the parameter is a symlink. With two parameters, it will create
# a symlink to a file or directory, with syntax: link $linkname $target
link() {
    if [[ -z "$2" ]]; then
        # Link-checking mode.
        if windows; then
            fsutil reparsepoint query "$1" > /dev/null
        else
            [[ -h "$1" ]]
        fi
    else
        # Link-creation mode.
        if windows; then
            # Windows needs to be told if it's a directory or not. Infer that.
            # Also: note that we convert `/` to `\`. In this case it's necessary.
            if [[ -d "$2" ]]; then
                cmd <<< "mklink /D \"$1\" \"${2//\//\\}\"" > /dev/null
            else
                cmd <<< "mklink \"$1\" \"${2//\//\\}\"" > /dev/null
            fi
        else
            # You know what? I think ln's parameters are backwards.
            ln -s "$2" "$1"
        fi
    fi
}

Also note a few things:

I just wrote this and briefly tested it on Windows 7 and Ubuntu, give it a try first if you're from 2015 and using Windows 9.
NTFS has reparse points and junction points. I chose reparse points, because it's more of an actual symbolic link and works for files or directories, but junction points would have the benefit of being an usable solution in Windows XP, except it's just for directories.
Some filesystems, the FAT ones in particular, do not support symbolic links. Modern Windows versions do not support booting from them anymore, but Windows and Linux can mount them.

Bonus function: remove a link.

# Remove a link, cross-platform.
rmlink() {
    if windows; then
        # Again, Windows needs to be told if it's a file or directory.
        if [[ -d "$1" ]]; then
            rmdir "$1";
        else
            rm "$1"
        fi
    else
        rm "$1"
    fi
}

Vaudois answered 19/8, 2014 at 23:56 Comment(22)

The parameters for ln aren't really backwards since it supports multiple parameters, you can just list a bunch of files and a directory as a destination and it will work :) Also, with the normal order it is similar to cp and mv which is less confusing. – Hydatid 3/1, 2015 at 16:36

@Hydatid See, it's great that I didn't try to create a "drop-in" solution, lol. I had no idea you could pass more than two paths to ln. – Vaudois 4/1, 2015 at 17:29

Unfortunately, this gives me You do not have sufficient privilege to perform this operation. – Capriccio 19/6, 2015 at 17:11

@Capriccio Are you trying that on a regular folder on your profile? Or some system directory? Also, which version of Windows? – Vaudois 24/6, 2015 at 16:27

@Capriccio That's wierd because that's what I'm using. Do you use MSYSGIT or some other Bash port? – Vaudois 27/6, 2015 at 4:56

Yes, it's the msysgit port. Maybe should add that I don't disable UAC. – Capriccio 4/7, 2015 at 18:25

@Capriccio That could be it! I disable UAC and run under administrator. – Vaudois 5/7, 2015 at 19:49

I used to think ln's parameters were backwards too, until I realized they were in the same order as cp's. – Moire 5/11, 2015 at 18:33

I tried your more comprehensive function, and it worked like a charm. THANK YOU so much! – Moire 5/11, 2015 at 19:35

Hey man, this is a really sweet answer, and this feels like nitpicking, but... WHY did you have to go and reverse the parameter order? it's "link target linkname" not the other way around. Pls. (Edit: OK I realize it's because you want the one-parameter overload to have it check the linkname if it is a link or not whereas unix ln does not do this. Point still stands though.) – Shirashirah 14/7, 2016 at 2:23

@StevenLu In retrospect, maybe I should have made it consistent with ln's parameter order, and used shift for the overload. Thanks for the compliment :) – Vaudois 15/7, 2016 at 7:50

ln's parameters seem intuitively "backwards" to me as well, though I can't think of any concrete benefit of having them the other way around. But, jeeze, this is an SO answer, not a library. If people want to switch the parameter order, they can switch the parameter order; no one is forcing them to copy&paste without modification! – Sugar 24/3, 2017 at 18:51

Also, it appears that this doesn't really handle absolute paths correctly. Now that cygpath is bundled with git-bash, I'd suggest using it to correct this issue by creating a variable target: target="$(cygpath -d ${1})" – Sugar 24/3, 2017 at 20:22

@KyleStrand Could you tell me what sort of absolute path was giving you troubles? Was it in the shape /foo/bar or /c/Users/foobar or C:\Users\foobar? – Vaudois 26/3, 2017 at 7:59

The first one. I didn't thoroughly check that this happened for all such paths, but it appeared that /c/Users/foobar somehow became /c/c/Users/foobar. – Sugar 26/3, 2017 at 17:41

I'm from the future but I forgot to buy Windows 9 on the way. – Epineurium 31/10, 2017 at 13:6

yes, ln's parameters are backward, even though it mimics cp's parameter order. – Cambogia 3/1, 2018 at 15:12

I don't think this has been mentioned, but it isn't best to use rm on a symlink. Instead unlink should be used. #210620 – Gaffrigged 14/3, 2018 at 11:52

The provided link function failed when the windows path has spaces. But It taught me how to use mklink native windows command, so did the trick. Thanks – Trefoil 1/4, 2018 at 10:45

I'm in 2019, still no Windows 9 :) – Dioecious 7/1, 2019 at 10:28

2023 here, still no Windows 9 :) – Milagrosmilam 8/4, 2023 at 1:26

@geedew, @CamiloMartin: I have problems with deleting the symlink: rmdir deleteme -> rmdir: failed to remove 'deleteme': Directory not empty // unlink deleteme -> unlink: cannot unlink 'deleteme': Operation not permitted – Perr 29/8, 2023 at 12:19

For my setup, that is Git for Windows 2.11.0 installed on Windows 8.1, export MSYS=winsymlinks:nativestrict does the trick as

The Git Bash shell may need to be run as an administrator, as by default on Windows only administrators can create the symbolic links.

So, in order to make tar -xf work and create the required symbolic links:

Run Git Bash shell as an administrator
Run export MSYS=winsymlinks:nativestrict
Run tar

Consensus answered 1/12, 2016 at 15:19 Comment(5)

it's the real answer~ – Herzegovina 26/3, 2019 at 10:21

you don't need to run as administrator if you turn on windows developer mode (requires Windows 10 version 1703 or later) learn.microsoft.com/en-us/windows/uwp/get-started/… – Phosphorylase 14/1, 2020 at 6:57

ln -s currentFile newLink also works with this approach (not just tar). The link created appears as a shortcut in windows explorer, but following the shortcut does not jump to the other folder's path, instead you see a path like C:\currentFolder\newLink. I have not seen a Windows link like this before! – Alisaalisan 16/6, 2020 at 16:23

I've developed an example with samples and images here: https://mcmap.net/q/49000/-how-can-i-make-symlinks-made-from-inside-docker-linux-containers-to-be-seen-from-a-windows-host-maybe-involving-samba-if-needed - Also back-linked from there to here. – Racecourse 9/8, 2020 at 11:15

real deal answer. – Trituration 11/5, 2021 at 20:7

It is possible, albeit extremely awkward, to create a symbolic link in MSysGit.

First, we need to make sure we are on Windows. Here's an example function to check that:

windows() { [[ -n "$WINDIR" ]]; }

Now, we can't do cmd /C, because MSysGit will fornicate with this argument and turn it into C:. Also, don't be tempted to use /K; it only works if you don't have a K: drive.

So while it will replace this value on program arguments, it won't on heredocs. We can use this to our advantage:

if windows; then
    cmd <<< "mklink /D \"${link%/}\" \"${target%/}\"" > /dev/null
else
    ln -s "$target" "$link"
fi

As a thank-you for the accepted answer, here's a more comprehensive function.

# We still need this.
windows() { [[ -n "$WINDIR" ]]; }

# Cross-platform symlink function. With one parameter, it will check
# whether the parameter is a symlink. With two parameters, it will create
# a symlink to a file or directory, with syntax: link $linkname $target
link() {
    if [[ -z "$2" ]]; then
        # Link-checking mode.
        if windows; then
            fsutil reparsepoint query "$1" > /dev/null
        else
            [[ -h "$1" ]]
        fi
    else
        # Link-creation mode.
        if windows; then
            # Windows needs to be told if it's a directory or not. Infer that.
            # Also: note that we convert `/` to `\`. In this case it's necessary.
            if [[ -d "$2" ]]; then
                cmd <<< "mklink /D \"$1\" \"${2//\//\\}\"" > /dev/null
            else
                cmd <<< "mklink \"$1\" \"${2//\//\\}\"" > /dev/null
            fi
        else
            # You know what? I think ln's parameters are backwards.
            ln -s "$2" "$1"
        fi
    fi
}

Also note a few things:

I just wrote this and briefly tested it on Windows 7 and Ubuntu, give it a try first if you're from 2015 and using Windows 9.
NTFS has reparse points and junction points. I chose reparse points, because it's more of an actual symbolic link and works for files or directories, but junction points would have the benefit of being an usable solution in Windows XP, except it's just for directories.
Some filesystems, the FAT ones in particular, do not support symbolic links. Modern Windows versions do not support booting from them anymore, but Windows and Linux can mount them.

Bonus function: remove a link.

# Remove a link, cross-platform.
rmlink() {
    if windows; then
        # Again, Windows needs to be told if it's a file or directory.
        if [[ -d "$1" ]]; then
            rmdir "$1";
        else
            rm "$1"
        fi
    else
        rm "$1"
    fi
}