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.
Related
So I have an interesting issue that I just can't figure out why I'm getting this and what to do.
So basically I store all my development projects on my Synology NAS for local access between my various devices. There has never been a problem with this until I started playing around with Elixir and more importantly Phoenix. The issue I am getting is when running mix phx.server. I get the following
[warn] Phoenix is unable to create symlinks. Phoenix' code reloader will run considerably faster if symlinks are allowed. On Windows, the lack of symlinks may even cause empty assets to be served. Luckily, you can address this issue by starting your Windows terminal at least once with "Run as Administrator" and then running your Phoenix application.
[info] Running DiscussWeb.Endpoint with cowboy 2.7.0 at 0.0.0.0:4000 (http)
[error] Could not start node watcher because script "z:/elHP/assets/node_modules/webpack/bin/webpack.js" does not exist. Your Phoenix application is still running, however assets won't be compiled. You may fix this by running "cd assets && npm install".
[info] Access DiscussWeb.Endpoint at http://localhost:4000
So I tried as it stated and ran it in CMD as admin but to no avail. After some further inspection I tried to create the symlinks manually but every time I tried I would get a Access is denied. error (yes this is elevated CMD).
c:\> mklink "z:\elHP\deps\phoenix" "z:\elHP\assets\node_modules\phoenix"
Access is denied.
So I believe it is something to do with the fact that the symlinks are trying to be created on the NAS because if I move the project and host it locally it will work. Now I know what you're thinking. Yes, I could just store them locally on my PC but I like to have them available between PCs without having to transfer files or rely on git etc. (i.e. offline access), not to mention that the NAS has a full backup routine.
What I have tried:
Setting guest read write access on the SMB share
Adding to /etc/samba/smb.conf on my Synology NAS:
[global]
unix extensions = no
[share]
follow symlinks = yes
wide links = yes
Extra logging on SMB to see what is happening when I try it (nothing extra logged)
Creating a symbolic link from my MAC (works)
Setting all of fsutil behavior query SymlinkEvaluation to enabled
At the moment I am stuck and unsure of what to try next, or even if it is possible. Considering just using NFS instead but will I face the same issues with SMB?
P.S I faced a similar issue with Python venvs a while ago, just a straight-up Access is denied. error and just gave up and moved just the venv locally and kept the bulk of the code on the NAS. (This actually ended up beingthe best solution for that because the environments of each device on my network clashed etc.)
Any ideas are greatly appreciated.
When I install composer on Windows 10, with active directory (meaning some of my user files live off on a server elsewhere), I get the following error when attempting to install:
Installation failed, deleting ./composer.json.
[InvalidArgumentException]
$from (\AD.LOCAL\SYSTEM\Users[path]\Application Data\Composer\ad.local\system\Users[path]\Applicat
ion Data\Composer\vendor\bin/boris) and $to (\AD.LOCAL\SYSTEM\Users[path]\Application Data\Composer\vendor
[path]\boris\bin\boris) must be absolute paths.
...very likely because my "Application Data" folder is not on my local machine.
How can I get around this. Windows composer install doesn't give me much in the way of options.
(Or, alternately, if I'm misinterpreting the cause of the problem, what is actually going on and how do I fix it?)
If your issue was during the installation there is a flag that allows you to set the installation directory.
The bin file from the path in the error message vendor/bin/boris doesn't look familiar to me and I am going to assume you completed an installation and a command had failed. There is a COMPOSER_HOME environment variable that impacts where a number of items are stored. This defaults to ${APPDATA}/Composer, if there are issues writing under that path for any reason, you can change the path by setting the COMPOSER_HOME variable for your user.
Created a local windows admin account, installed the functions from that account, and then put the local admins roaming folder in my PATH. Ugly, but effective.
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.
In VS 2010, I have a post-build event copying project assemblies into a common .dll folder. The .dll folder is mapped by a virtual drive (R:).
On running, I get the following: The command "copy /y "C:\CommonDLLs\Utilities.dll" "R:\"" exited with code 1.
The thing is, when I run copy /y "C:\CommonDLLs\Utilities.dll" "R:\" at the command prompt, it works correctly. I'm running VS as an admin, so I should have permissions to execute the command. Other people using the same code from source control are having no problems, but I'm stumped as to what to fix to get the copy to work correctly. Anyone have any suggestions?
EDIT: more information
The R drive is mapped/created/populated initially by a .bat script that I run as an admin as well. if I update my scripts to run to the location the R drive points to, everything runs ok, so I think this might be a drive mapping issue. The thing is, I(as a local admin) have full control over both the folder and the drive mapping.
I would guess that the virtual drive does not exist under the Admin account and as such cannot be found.
Either don't run VS as Admin, or set up the virtual drive in an command prompt running as Admin.
The postbuild task for one of our solutions uses xcopy to move files into a common directory for build artifacts. For some reason, on my computer (and on a VM I tested), the xcopy fails with "Access Denied". Here's what I've done to try and isolate the problems:
I tried a normal copy; this works.
I double-checked that none of the files in question were read-only.
I checked the permissions on both the source and destination folder; I have full control of both.
I tried calling the xcopy from the command line in case the VS build process had locked the file.
I used Unlocker and Process Explorer to determine there were no locks on the source file.
What have I missed, other than paranoid conspiracy theories involving computers out to get me? This happens on my dev machine and a clean VM, but doesn't happen for anyone else on the project.
/r = Use this option to overwrite read-only files in destination. If
you don't use this option when you want to overwrite a read-only file
in destination, you'll be prompted with an "Access denied" message and
the xcopy command will stop running.
That's was mine resolution to this error.
Source
Problem solved; there's two pieces to the puzzle.
The /O switch requires elevation on Vista. Also, I noticed that xcopy is deprecated in Vista in favor of robocopy. Now I'm talking with our build engineers about this.
You need to run XCOPY as Administrator, there is no way around this.
If you don't want to run your copy as Administrator, then you must use ROBOCOPY instead.
Note, however, that with ROBOCOPY it is very tempting to use the /COPYALL switch, which copies auditing info as well and requires "Manage Auditing user right", which again invites you to run as Administrator as a quick solution. If you don't want to run your copy as Administrator, then don't use the /COPYALL (or /Copy:DATSOU) switch. Instead use /Copy:DATSO, as the U stands for aUditing.
Also note that if you are copying from NTFS to a FAT files system, there is no way you can "Copy NTFS Security to Destination Directory/File".
Usually this happens because there's another process locking the file. I bet your machine has a different number of cores/different speed than the others. Try inserting some sleeps to see if it solves the problem.
If you can delete the file in Windows Explorer, try using an elevated command prompt. Not sure why Windows Explorer does not ask permission here for a delete operation that needs admin rights via cmd.
if you are copying file to IIS folder, then you need run the batch file as admin.