rlucas.net: The Next Generation Rotating Header Image

Don’t bother with symlinks in Windows 7

Yes, in theory, Windows has rocketed into the 21st century with symbolic links. However, you can’t make them in Windows 7 unless you’re an Administrator, or unless you manage to give yourself “SeCreateSymbolicLinkPrivilege.”

Giving yourself this privilege is possible with Professional/Ultimate versions of Windows, but not Home Premium, via secpol.msc, which just doesn’t exist (and can’t be downloaded). (Funny, I don’t recall the comparison chart having a checkbox for “can actually use computer” that was missing from Home Premium.)

If you try to set this for yourself, don’t bother trying to use C# or PowerShell. You’ll need to manually wrap the unmanaged C++ advapi32 APIs, and pass all kinds of structs and pointers back and forth.

In the end, just give up on whatever it was you wanted to use symlinks for.

7 Comments

  1. Dan Shapiro says:

    Huh? I used mklink all the time, and it’s great – easiest way to get My Docs off your C: drive (in my case a small SSD) and move it elsewhere. Also works for other magic directories like PROGRAMDATA.

  2. rlucas says:

    1. Technically, it’s “cmd /c mklink”, because mklink is a cmd.exe builtin and not its own program. (This will save PowerShell users the confusion.)
    2. Yes, you can use it as you described, but only if: A. you’re Administrator (effectively), or B. your local security policy gives normal users the SeCreateSymbolicLinkPrivilege.
    3. If you don’t have the “professional” or “server” versions of Win 7, you won’t have the required program(s) such as secpol.msc that let you manipulate your own security policy.
    4. Hence, if you want a more repeatable and reliable solution than “start PowerShell as Administrator manually with some right-clicking,” you’re up Shit’s Creek. (Example: you might want to run a script to set up everyone’s development sandbox with appropriate local env vars and config files, all of which are version controlled, but only one of which should be the local active copy on any individual box. You can rely only upon the standard facilities of PowerShell. Symlinks are right out because you can’t guarantee that SeCreateSymbolicLinkPrivilege is enabled, or even *can be* enabled, on each dev’s box.)

    Yes, I know, one could always “runas /user:Administrator”, but then by doing that we’ve effectively destroyed the “least privilege” principle, because the answer to any hurdle becomes to adopt the *most* privilege.

  3. Jan-Erik Finnberg says:

    You can give your normal user account the permission with polsedit:

    http://polsedit.southsoftware.com/

  4. kika says:

    You are forgetting that most people run standard in admin mode. So its not a problem for those.

    Most people I know run with a hacked code, so they all have ultimate of course.

    It’s not an issue.

  5. Kika is wrong here. It is an issue. Just because it’s not an issue for a subset of users (power users), the “workaround” violates good security principles (not running common commands as administrator) and doesn’t account for some environments where the workaround is simply not viable.

    Rlucas is right that if the privilege to create symbolic links is not present by default, it should at least be possible to enable it in as straightforward fashion with no more than one (built-in) command (or powershell script), but as he points out, it is not.

    Finally, I wanted to add that this is not the only surprise regarding symbolic links. Did you know that if you try to delete a directory tree using Powershell and that tree contains a symbolic link to another directory, Powershell will _traverse_ that symbolic link and recursively delete its content too?

    Let’s hope our friend Dan Shapiro doesn’t try to remove one of his symbolic links using Powershell and accidentally delete all of his Documents.

    If you think that’s ugly, please vote for the issue in MS Connect: https://connect.microsoft.com/PowerShell/feedback/details/727149/powershell-rm-rec-traverses-symbolic-links-and-removes-items-in-target

  6. John Guidry says:

    Not sure if you found a workaround for this, but I finally did. I also share your deep seated rage that something so fundamental requires jumping through hoops if you didn’t upgrade to Win7 Pro — ridiculous! The fix is a two-parter.

    First, cygwin ships with editrights.exe which handles at least some of the missing secpol snap-in’s duties. Start your cygwin term as administrator and issue the command:

    editrights -a SeCreateSymbolicLinkPrivilege -u [USERNAME]

    The command should work without an error. If your user is not an administrator, then you should be set now. You can verify your privilege list by opening cmd and issuing `whoami /priv`. If you are an administrator (likely), there’s more to do. You can read all the low-level details at StackOverflow.

    http://stackoverflow.com/questions/15320550/secreatesymboliclinkprivilege-ignored-on-windows-8

    Since I don’t consider disabling UAC a valid solution, I created a new user named root to be my administrator account and made my primary account a standard user. Now try `whoami /priv` again. SeCreateSymbolicLinkPrivilege should now be listed and mklink should function without elevating your permissions.

    Hope this helps!

  7. rlucas says:

    Wow, great, meaty comment. Thank you. I give thanks this Thanksgiving holiday that I am not in a work situation that requires any obligate Windows operating system usage. ;)

Leave a Reply