Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Friday, January 11, 2013 3:55 PM
I need to use a unc connection for end users to run a batch file that copies files from that directory back to there local machine. I have given the users full control on the folder containing the batch file. But I get and error that says "Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item."
The file can be run from a cmd line using pushd.
Where does this question belong?
All replies (17)
Friday, February 1, 2013 4:34 PM ✅Answered
Turns out the answer was one of two things.
1. Turned off Internet Explorer Enhanced Security under Windows option on the local computer.
2. Open IE8 for the first time on the local machine. Answered all questions for the Run Once screens.
I am not sure why this was the case as I was not using IE to access the remote server. The files I was trying to copy over were related to web site builds.
Anyway it's working.
Saturday, January 12, 2013 2:37 AM
I need to use a unc connection for end users to run a batch file that copies files from that directory back to there local machine. I have given the users full control on the folder containing the batch file. But I get and error that says "Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item."
The file can be run from a cmd line using pushd.
Where does this question belong?
What is in the batch file?
¯\(ツ)_/¯
Saturday, January 12, 2013 6:08 AM | 3 votes
batch files tend to puke if they're working from a UNC path. The reason that your trick works is that pushd essentially does an automatic drive map for you.
It might help to see the content of your script as jrv requests, but one general trick that _should_ resolve your problem IIRC is to make the first line of the batch file
pushd %~dp0
This will automatically force a temporary drive mapping to the root of the share, and file copy operations should then work fine.
If you don't do this, then cmd.exe squawks about not being able to run with a UNC path as its current directory. It _will_ still run anyway, but will default to your Windows or System32 directory, which is probably not where you want your users to be copying from.
FYI, to check something like this in a click-to-run batch file, you can do your own debugging by inserting the following commands to show your location and halt the batch script so it can be viewed -
echo %CD%
pause
Saturday, January 12, 2013 6:46 AM
Alex has probably nailed it. Yes - I overlooked the fact that your copy was from the UNC current drive which can be an issue. You can explicitly use the UNC path in the copy command as this is an easy way to make it work. Alex method is better if you have a lot of commands that work on the current folder.
copy \server\share\folder <some local path>
This will workaround the failure when defaulting the local path. where: copy file.ext <local path> might fail.
OR
copy folder\file.ext ...
OR
copy .\file.ext
Those will fail much of the time.
¯\(ツ)_/¯
Monday, January 14, 2013 8:08 PM
1. I added the pushd %~dp0 cmd at the begining of the batch file and it was a no go. It seems as if the file is blocked from even opening. I am a domain admin trying to access this file and the end user trying to access has read and execute permissions.
2. I also added the echo %cd%. Where is the output of that logging command written?
3. The first line of the batch file looks like this and the rest is similar:
xcopy /y /e /k \NAS\Dept\commerce\folders_to_copy\wesley\customer\customerfile f:\sites\customersite
Monday, January 14, 2013 8:44 PM
Hi,
When you say that something didn't work, you have to say how it didn't work. ("It was a no go" doesn't really convey any useful information.)
Where is your error message appearing? In a Windows GUI dialog box or the cmd.exe console window? (A screen shot is probably appropriate.)
Does the user that's running the script (batch file) have sufficient share permissions along with sufficient file system permissions?
Bill
Monday, January 14, 2013 8:54 PM
1. I added the pushd %~dp0 cmd at the begining of the batch file and it was a no go. It seems as if the file is blocked from even opening. I am a domain admin trying to access this file and the end user trying to access has read and execute permissions.
2. I also added the echo %cd%. Where is the output of that logging command written?
3. The first line of the batch file looks like this and the rest is similar:
xcopy /y /e /k \NAS\Dept\commerce\folders_to_copy\wesley\customer\customerfile f:\sites\customersite
Why use XCOPY for a single file?
copy \NAS\Dept\commerce\folders_to_copy\wesley\customer\customerfile f:\sites\customersite
You can test access like this:
dir \NAS\Dept\commerce\folders_to_copy\wesley\customer\customerfile
Along with being an admin the admin group must have permissions on this location. User foilders do not have admin access by default. Only the user has access.
¯\(ツ)_/¯
Thursday, January 17, 2013 10:04 PM
Sorry about that. Here is a screen shot of the error that appears when I try to execute the batch file that is circled.
I am running as a domain admin acct connecting to the remote computer with the same creds. As already listed in this thread the batch file just copies folders and files from this remote location to a local drive. I don't think it has anything to do with the batch file itself as it doesn't seem to even try to execute the file, but rather access is restricted. As a Domain admin I have full control on both the remote folder and the local drive. There is another user who is not a domain admin and he can execute the file with no problem. I am really at a loss.
Thursday, January 17, 2013 10:09 PM | 1 vote
Hi,
Since your script works, you don't have a scripting problem but a share and/or file system permissions problem. I recommend asking in a more appropriate forum.
Bill
Thursday, January 17, 2013 10:13 PM
Along with being an admin the admin group must have permissions on this location. User foilders do not have admin access by default. Only the user has access.
¯\(ツ)_/¯
The Domain Admin Group, of which I am a member, is nested in the local admin group on the local machine. The Local Administrators Group has full control of the drive that should be the recipient of the copied files.
On the remote computer, The Domain Admin Group has full control of the folder where the batch file resides, as well as the batch file itself.
Friday, January 18, 2013 3:20 AM
<None of this may be relevant; I'm leaving it in place, but see following comment by jrv and my response>
I'm somewhat at a loss about what to make of this at this point, given the details you've provided. One other question before diving into this again is - what is your goal? Are you trying to just run this particular batch file as an admin without needing to pushd into the folder each time? If so, there's an easy alternative using a shortcut or a local batch file. If you have another, similar need there are other, similar solutions that don't involve lots of heavy analysis - based on the context, I kind of assume you're more concerned about performing a specific task consistently and economically than detailed analysis of command resolution mechanics. ;)
If that's not viable: Assuming that nothing was changed during your troubleshooting so far...the following all appear to be true:
+ the file is located in a folder 'owned' by a normal user on your network, and he has no problem running the batch file, even without the pushd in the script, and apparently even if he runs the batch file by double-clicking on it in the Explorer UI. (question: are you absolutely, totally positive that it is run by that user, without the user having any mapping whatsoever to that shared location, and without using pushd either? It's not the user's home folder on the network?)
+You can run the file if but only if you perform a pushd into that location prior to executing the batch file.
+ If you try to run the batch file from a command prompt (not the explorer GUI!) without an explicit pushd into the location, the script fails to run.
If you are certain of all of the above points, then there's something odd going on here - for one thing, I would expect the batch file to *not* work for the user under the conditions described. Could you confirm the following further details:
- the operating system version run on the end user's machine.
-the OS on your system.
- OS and domain role of the server which actually shares the files - if this is a *nix-based NAS device that works via SAMBA, something like this is possible. Knowing the OEM for the NAS device and its provenance (model and firmware version) could provide the answer if the above details really all are correct.
- Also do a check with the user - have him or her open a cmd prompt window when logged on the network and then run the command SET. Check the variables HOMEDRIVE,HOMEPATH,LOGONSERVER, and USERPROFILE. Any of those could force transparent mapping of that path for the user, which would explain why he/she can run the batch file with a simple explorer double-click even through the share path.
Friday, January 18, 2013 3:26 AM
Alex - very nice but...
Read the OPs last post. You will see that this is not the issue.
Synopsis:
"The Domain Admin Group, of which I am a member, is nested in the local admin group on the local machine. The Local Administrators Group has full control of the drive that should be the recipient of the copied files."
"On the remote computer, The Domain Admin Group has full control of the folder where the batch file resides, as well as the batch file itself"
¯\(ツ)_/¯
Friday, January 18, 2013 6:43 AM
Alex - very nice but...
Read the OPs last post. You will see that this is not the issue.
Synopsis:
"The Domain Admin Group, of which I am a member, is nested in the local admin group on the local machine. The Local Administrators Group has full control of the drive that should be the recipient of the copied files."
"On the remote computer, The Domain Admin Group has full control of the folder where the batch file resides, as well as the batch file itself"
¯\(ツ)_/¯
Oops - I guess I _did_ overlook the obvious. And in any case, nothing I described would explain the GUI error occurring when things work from a command prompt.
The one thing that would explain it is possibly a security setting involving network path use. What about the following 2 checks:
(1) does the error _always_ occur when clicking to run on \nas02\Departments\blah-blah>\mcarlos\cPortHB\2003-cPortHB.bat ?
(2) Map a drive to \nas02\departments. Assume the drive is Q:. Navigate to Q:\.....\mcarlos\cPortHB and then click-to-run on 2003-cPortHB.bat. Does the error occur now?
Friday, January 18, 2013 6:46 AM
2. I also added the echo %cd%. Where is the output of that logging command written?
FYI, this isn't logged anywhere. It simply echoes the current directory to the command window. Since you're doing a click-to-run, the next line I mentioned - the pause command - is critical since it will pause the output until you strike a key, allowing you to see the output. If you don't have an "echo off" line in the batch file, you would then see output like this:
C:\Windows
C:\Windows>pause
Press any key to continue . . .
Friday, January 18, 2013 6:48 AM
Yeah - sometimes it is hard to communicate with non-technical users so the thread gets very long; that makes it hard for anyone to keep up with the original request,
I knew you just missed the details in the noise.
¯\(ツ)_/¯
Friday, January 18, 2013 6:52 AM
2. I also added the echo %cd%. Where is the output of that logging command written?
FYI, this isn't logged anywhere. It simply echoes the current directory to the command window. Since you're doing a click-to-run, the next line I mentioned - the pause command - is critical since it will pause the output until you strike a key, allowing you to see the output. If you don't have an "echo off" line in the batch file, you would then see output like this:
C:\Windows C:\Windows>pause Press any key to continue . . .
Alex - look closely at the error. The batch never execute so your suggestion will never get used.
The OP has an issue with either permissions or with cross system authentication. It is impossible to explain to a non-admin how this can happen or how to troubleshoot this. It cannot be fixed in script and the script cannot be executed so no amount of tracing code will help.
¯\(ツ)_/¯
Friday, February 1, 2013 5:16 PM
That I not an answer. It is a clue that you "local machine zone" is not set to trust the network. What you have done was to disable an important security measure which is one thng that Trojans try tofool you into doing. Ypu are noow not protected.
This should be moved to the IE forum. It is not scripting issue.
¯\(ツ)_/¯