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.
  • Does your local path or network path have spaces in them? If so, are you encapsulating the path with double quotes at the start and end of the path?
    – Sun
    Sep 5, 2013 at 5:00
  • @SunWKim No spaces in either path.
    – Craig W
    Sep 5, 2013 at 6:04
  • what is the command line you are using to perform the backup from local to network? What kind of network share are you backing up to? Makes me think perhaps the network share is not available (not connected) when you perform the backup command.
    – Sun
    Sep 5, 2013 at 16:33
  • Is it running as your user or just "an admin." If it's your user, is the drive persistently mapped for your user?
    – Nick
    Sep 5, 2013 at 22:40
  • @SunWKim Yes, the drive is connected after mapping. The local admin does not have rights to the network share which is why I have to map it as a different user before running Robocopy.
    – Craig W
    Sep 9, 2013 at 15:03

15 Answers 15


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.

  • Not possible. The computer is not on the domain so I have to run the task as a non-domain user but only domain users have access to the network share.
    – Craig W
    Sep 6, 2013 at 17:14
  • I know this is very late to the game, but have you tried separating your work into 2 scheduled tasks, one for the network share with domain credentials and then another one running as local admin with access to the mapped drive? You would just have to stagger them or use a file mutex or something to make sure they go in order. Aug 14, 2017 at 13:33

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.


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


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.

  • This also worked for me - the network drive mapping seem to be set up as part of the login session. Checking that option causes the task to run in the login session, and so the drives are available.
    – WillW
    Jun 8, 2021 at 9:30

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.


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.

  • Welcome to Super User! Please read the question again carefully. Your answer does not answer the original question. OP makes no mention of using Cygwin or bash.
    – DavidPostill
    Nov 9, 2016 at 11:37
  • @DavidPostill While, the OP only asked about robocopy, this question is now a top search result for the more generic query "task scheduler copy from network drive". This particular answer also works for cp which allows for copying single files (as opposed to robocopy which can only copy whole directories)
    – thehale
    Nov 28, 2021 at 17:20
  • 1
    @jhale1805 If you read the link you posted "However, you can robocopy single file with the right filtering which you’ll learn about below. To robocopy a single file file, specify the source and destination directories immediately followed by the file name in the source." robocopy c:\src d:\dst copythisfile.txt
    – DavidPostill
    Nov 28, 2021 at 17:27
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.

  • 1
    This fixed the issue for me! having this command to login with authentication to execute before the script did wonders! This solves the headache of having to "mirror user accounts" with something robust. Jun 1, 2018 at 10:51
  • 1
    First time I've helped someone on stack overflow, glad I could help. Also, use "echo Get-Date" instead of what I had before. Jun 2, 2018 at 23:11
  • I didn't need the logging, so i just added a cmd /c net use job entry before the copy job entry in the task and that fixed my issue. Your post was the first after four hours encountering suggested mirror accounts that provided an easy solution. Keep up the good work! Jun 2, 2018 at 23:17
  • You are still maintaining the UNC paths with this script so you know. Just because you are assigning a drive letter to a UNC path and then referring to that drive letter, you still have to maintain the \\ServerName\ShareName in this sort of logic. Additionally, this does not necessarily need to be PowerShell since NET USE runs via batch as well and as far as scheduling with Task Scheduler as the SYSTEM account, you can do that regardless of what type of script, logic, etc. you schedule to run via Task Scheduler. Jun 2, 2018 at 23:26
  • Furthermore just to clarify, please note you could also use NET USE \\<ServerName>\<ShareName> <password> /user:<domain>\<username> just like that and not have to specify a drive letter at all if the authentication alone to the share is what is needed rather than the actual drive letter. Jun 2, 2018 at 23:30

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.

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.


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.


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


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


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.


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.

  • 1
    Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Sep 4, 2023 at 21:31

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.

  • This does not answer the author's question. Please don't leave comments as answers.
    – Ramhound
    Apr 21, 2016 at 20:55
  • Please don't add "thanks" as answers. Invest some time in the site and you will gain sufficient privileges to upvote answers you like, which is the Super User way of saying thank you.
    – DavidPostill
    Apr 22, 2016 at 11:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .