Access is denied on mklink - windows-7

I am trying to get a symlink working over a network drive.
I have already tried suggestions on questions already asked, such as running as administrator and checking if the directory already exists. Unfortunately it still gives me the following error:
C:\Windows\system32>mklink /d \\myserver\someLink \\myserver\mydir
Access is denied.
Any ideas how I could get this working? The local machine is running windows 7 and the remote machine is running windows server 2008 R2 standard.

I jumped through all the hoops:
Create a non-admin account (in my case, activated the guest account).
As Admin, run secpol.msc and grant this account Create Symbolic Link permissions.
runas /user:guest cmd to open a command window as the guest.
only to get caught on the simplest problem: because I was running as guest, I didn't have write permissions within the directory. So,
As admin, change permissions in the target directory (where you want to make the link) to give write access to the non-admin user.

I had this while I wanted to create a hard link with mklink /H ....
By removing the /H, the error vanished as well.
So if a symbolic link does the trick for you as well, you should try this.

This is a little silly, but make sure you're using /D (soft) or /J (hard) for directories or you'll get access denied.

Related

mklink error on domain connected machine but valid symlink still created - "the system cannot find the file specified"

On domain connected Windows 10 and Windows 8.1 machines (issue may not be version specific), running mklink symlinkToCreate.txt originalFile.txt is producing an error The system cannot find the file specified. The symlink is still created correctly.
I have made sure that originalFile.txt does exist and that symlinkToCreate.txt does not already exist. I have also tried using absolute paths for both parts instead of relative paths. I am using an elevated command prompt as I know that only elevated Administrators can create symlinks by default. I have also checked the Create symbolic links local policy and confirmed that this is just set to Administrators.
Directory link creation also produces the error (mklink /D). Hard link creation, however, works fine (mklink /H).
Weirdly, I get the same behaviour even when logged in using the local Administrator account. I also get the same behaviour on a different machine in the same domain. The exact same commands work perfectly on a non domain-connected machine.
Given that mklink is built into cmd and that the file I'm linking definitely exists, I'm stumped as to what file the system cannot find, though I strongly suspect that the actual content of the error is a red herring. Shame there doesn't seem to be a mklink debug mode!
Any pointers greatly appreciated as I'm banging my head against a wall with this one.

Windows directory with no permissions

I accidentally removed all permissions from a directory on a Windows 2008 server. I can see the directory when listing contents of its parent both through Windows Explorer and DOS, but I can't do anything else. No matter what I try, the system essentially acts like I'm trying to work with a directory that doesn't exist. Trying to change the permissions through Windows Explorer yields a message that the security information is not available (on the Security tab). I've also tried takeown and modifying permissions with icacls, both of which report file not found. My account is part of the Administrators group. The account that created the folder (the owner before I messed up the permissions) can't even see the directory when listing contents of its parent. dir /q reports the owner of the directory as "...". Is there anything that can be done here or is this directory lost?
The solution here was to log in using the local administrator account and run takeown /F on the directory in question. From there, I was able to reset the permissions of the directory and all of its contents.

mklink access denied but explorer succeeds

Trying to create link on file share using:
mklink /D "\fileshare\dest\folder_link" "\fileshare\dest\folder"
(under Admin)
But it gives access denied, tried to run fsutil, but no success :(
fsutil behavior set SymlinkEvaluation R2R:1
C:\Windows\system32>fsutil behavior query SymlinkEvaluation
Local to local symbolic links are enabled.
Local to remote symbolic links are enabled.
Remote to local symbolic links are enabled.
Remote to remote symbolic links are enabled.
However when I try to create link via explorer ( right clicking, selecting Create shortcut )- it works.
Why command line doesn't not work, but explorer does ?
Is there an alternative way to create soft links via cmd?
So it appeared to be GPO policy for linking not set on the machine that was hosting the fileshare.
secpol.msc, Local Policies\User Rights Assignment\Create symbolic

Permissions and SVN Updates on Windows Server 2008: same folder & SVN account, different Active Directory users

We're experiencing strange permission issues with SVN after switching from Windows Server 2003 to Server 2008.
On our standard build box there is a folder (C:\SVN_Code_Folder) which AD_User_A associates with a SVN repository using SVN_User and TortoiseSVN 1.7.6
When using Windows 2003, when AD_User_B logs into the box and tries to Update, Switch, Merge the SVN_Code_Folder with SVN_User, the command is executed.
It Windows 2008, it fails with the message:
Command: Update
Error: Working copy 'C:\jboss-4.2.3.GA\server\New folder' locked
Error: sqlite: attempt to write a readonly database
Error: sqlite: attempt to write a readonly database
Completed!
Attempting to unlock the file, which was never locked, via the context menu is met with the following message:
There's nothing to unlock. No file has a lock in this working copy.
I've played with the permissions of the folder and I've discovered that giving "Domain Users" control over the folder fixes the issue, but I would prefer to not have such a broad permissions. I've tried granting the same permissions to individual users and a SVN-group, but these too did not work.
What am I missing?
Is this an improper use of SVN?
Can 2 different Domain users update a folder using SVN without removing the .SVN file?
For future reference...
I had this same problem with some WC's that I copied over to my new laptop's hard drive, from a file share on my old machine.
It turned out that the problem was solved by giving myself (as opposed to all domain users, or any other group) full control over the folder.
Did you check the svn service user on the win2008 machine?
Does that user have local administrator privileges and also have permission to these folders on c:?
After changing anything restart the service.
For me change folder permissions did't help, but I have update for several directories in a batch script so I solved this by
cmd -> Run as administrator -> start update script

Jenkins calling batch file on mapped drive

I have a Jenkins job that calls a batch file on a ClearCase drive (V:).
My Jenkins slave agent is running as a service using a local admin account.
The Jenkins job does the follow:
cleartool startview MY_VIEW
cd /d "V:\MY_VIEW\Build"
call PrepareBuild.bat
When I run the Jenkins job, I keep getting "Access is denied." in the Console Output when it tries to call the batch file. However if I manually run the above in command prompt, it completes successfully.
I did not have this problem under Windows XP. Does anybody know why this is happening on Windows 7 (32-bit)?
Thanks.
The V:\ is a virtual drive obtained with the windows command subst.
It is a shortcut between the root directory of your dynamic view (M:\yourView) and the virtual drive.
(Ie, V:\ is not particularly linked to ClearCase. It is just a drive letter the user wishes to associate to a certain ClearCase view root directory)
However, ClearCase registers that association in the registry HKCU/software/atria/....
Which means the ClearCase session run under the local admin account for Jenkins won't know about said association and the need to restore that virtual drive.
A workaround would be to make that drive permanent, using psubst.
That register the drive path in [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices], and HKLM is accessible from all accounts.
See " How to make SUBST mapping persistent across reboots? "
I had the same problem. Had a simpler solution.
Jenkins doesn't have access to folders that only the user has access to (even though its run by the user). So the folder which is getting access denied you need to set folder permission to everyone not the user

Resources