Why can't a Task Scheduler job access a mapped network drive?

Question

I have a Task Scheduler job to run Robocopy for backing up local files to a network share. I have to use domain credentials to access the network share but the local computer is not on the domain, and the job is run as a local admin. This solution of temporarily mapping and unmapping the network share works but it leaves my password exposed in plain text for anybody who looks at the Task Scheduler job actions. I would prefer to map the network drive normally on a semi-permanent basis so the Task Scheduler job just has to run Robocopy and refer to the appropriate drive letter. However I always get the error "The system cannot find the path specified." in the Robocopy log when running this from Task Scheduler, even though the command works fine from an elevated command prompt (job is set to run with highest privileges). Also note I have done this registry tweak to access mapped drives from an elevated command prompt.

EDIT: To clarify, logged in as the local admin, I launch Windows Explorer as administrator. I map the network share to drive letter Y. I launch the command prompt as administrator and run

C:\Windows\System32\Robocopy.exe C:\temp Y:\temp

Works fine. I create a Task Scheduler job to run the exact same command, whether user is logged in or not, with highest privileges. I run it and get an error. I write to a log and get

ERROR 3 (0x00000003) Getting File System Type of Destination Y:\temp\
The system cannot find the path specified.

followed by

ERROR 3 (0x00000003) Creating Destination Directory Y:\temp\
The system cannot find the path specified.

Answer 1

Mapped drives are a User Interface concept and are not available to background tasks like that. Access the target via UNC and make sure that the user that the task runs as has access to the target.

Answer 2

In my case all i had to do was uncheck the run with highest privileges flag but im running the task in on the same user as the user who mapped the drive.

Answer 3

Try using:

pushd \\machine\share

within a batch file of your scheduled task. Network shared drives are only available from a user-run environment. "pushd" will allow it to be run in the context of the script.

When you're done use:

popd \\machine\share

to unmap the drive.

Reference: https://blog.adrianbanks.co.uk/windows/2007/03/08/accessing-network-file-shares-from-a-command-prompt.html

Answer 4

I overcame the problem by changing the option "Run Whether user is logged on or not" to "Run only when user is logged on". Try this it may help you.

Answer 5

Another option is just to use the full network path, as Robocopy supports them. i.e. robocopy c:\temp \\server\share\temp

Or better yet, run the backup on the server itself. Create a domain admin account just for the backup process. Feed robocopy the password from a text file that only domain admins can access.

Years ago I created several .cmd scripts that would backup essential files for every system on the network this way. The only external program that I used was Cgywin's Grep command, and a command prompt smtp mail sender.

I made one script that would scan the network for systems. It would create a text file of all the system names, and alert me via email of any new systems that it found. (I had a config file that it would parse for systems to skip.) Each new system had a backup directory created for it and an backup configuration file placed in it. The user could modify this file and list any directories that needed backed up. They could also specify the time for their backups so it wouldn't happen when they were in the office. I ran this script on the server every 5 minutes, as it took no processing time and I like the security feature of alerting me when a new system was plugged into the network.

Another script would parse all of the individual backup configuration files and schedule a task to run a backup on that system. This was run daily at 12:01am.

Finally the backup script would parse the config file that was passed to it by the scheduler and using robocopy would copy all of the files. I had full error checking on the config files since users would edit them, and I would get emails on any problems.

The users could read their backup files, but could not delete the backup. This provided some protection from damage from a possible disgruntled employee.

Probably something much more elegant could have been made in .vbs or powershell, but I am not really a programmer. My programming classes included Cobal and JCL. I remember I copied the scripts when I left, but who knows where they are now.

Answer 6

I had same issue trying to access r:/xxxfilename.txt with a windows mapped drive r:\server\share when calling a script from windows task scheduler.

I solved using //server/share/xxxfilename.txt
Please notice the back slash converted to forward slash.
Now my bash cygwin script runs in windows task scheduler and cygwin shell.
Note: "net use" command can access the map drives in shell but shows Unavailable R: when I run this command in Windows task Scheduler.

Answer 7

echo Get-Date >> c:\mount_nfs_log.txt
net use X: \\share\folder password /user:domain\user>> c:\mount_nfs_log.txt 2>&1

Creating this powershell script, scheduling the job as SYSTEM and setting it to run on reboot allowed me to use drive letters in my scripts since UNC isn't an option due to a headache of other issues.

Answer 8

Use an SMB path in your robocopy command, rather than a drive letter. Or alternatively map the drive at the beginning of your script. If you get access denied:

• Goto settings or control panel and search for Credential Manager.
• Once in Credential Manager, goto Windows Credentials, then Add a Windows Credential.
• Type the computer name that you are connecting to, along with a username and password that can authenticate on that machine.

Answer 9

Try changing the "start in" location to "c:\". This seemed to fix it for me so maybe the system was preventing the cmd.exe from executing from the default \windows\system32\ as a security feature.

Answer 10

As another user noted, setting the option to "Run Whether user is logged on or not" to "Run only when user is logged on" does seem to work. You can then use either the mapped path (e.g. Z:) or the server path (e.g. \\ServerName\Path).

Of course, if you use this option, then you have to do as it says and ensure that you have logged into the server as a user with access to the relevant drive. I remember being at an older company with a number of jobs setup like this. One day someone "signed out" of the main jobs server, not expecting that that would have any kind of impact as they weren't shutting down the machine in any way...

Also, these days, Windows likes to do a lot of self invoked system reboots. So use this solution at your own risk.

Answer 11

Also note that if you make the mapping in the script and the password contains % then it has to be written %% for the script to work from the taskscheduler but % to work from commandprompt

Answer 12

one can use following commands, to be added in the batch script itself, to run Batch script from windows schedule task to get dir,file copied onto the local system using Windows schedule task; net use Y: "\\xxx\xxx\xxx cd /d Y: net user /d Y: /Y

Answer 13

If you know remote device address then you can use NET USE to temporary map network drive. For example in batch file, before executing your code, you can write something like this:

if not exist "Y:\temp" (
    echo Mapping network drive... 
    net.exe use Y: \\machine\share\temp /persistent:no
)
notepad.exe Y:\temp\robocopy.log

If the drive was already mapped by the account user then you don't need to hardcode the credentials.

Answer 14

Just solved a similar problem after lots of hours or trial and error by setting "When running the task use the following user account" > press Change User or Group button > press Advanced button> press Find button > Choose "Administrators" as in the AdministratorS group not Administrator user.

Answer 15

Thanks , i think that using "start in c:\" solved my problem i will be tracking this issue to confirm is solved.

I was having the same issue , if i clicked directly on batch it ran flawlessly but not under scheduled task.