Why can't a Task Scheduler job access a mapped network drive?
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:WindowsSystem32Robocopy.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.
windows-7 task-scheduler robocopy
|
show 2 more comments
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:WindowsSystem32Robocopy.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.
windows-7 task-scheduler robocopy
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 '13 at 5:00
@SunWKim No spaces in either path.
– Craig W
Sep 5 '13 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 '13 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 '13 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 '13 at 15:03
|
show 2 more comments
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:WindowsSystem32Robocopy.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.
windows-7 task-scheduler robocopy
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:WindowsSystem32Robocopy.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.
windows-7 task-scheduler robocopy
windows-7 task-scheduler robocopy
edited Sep 6 '13 at 16:10
Craig W
asked Sep 4 '13 at 17:21
Craig WCraig W
4211610
4211610
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 '13 at 5:00
@SunWKim No spaces in either path.
– Craig W
Sep 5 '13 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 '13 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 '13 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 '13 at 15:03
|
show 2 more comments
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 '13 at 5:00
@SunWKim No spaces in either path.
– Craig W
Sep 5 '13 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 '13 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 '13 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 '13 at 15:03
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 '13 at 5:00
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 '13 at 5:00
@SunWKim No spaces in either path.
– Craig W
Sep 5 '13 at 6:04
@SunWKim No spaces in either path.
– Craig W
Sep 5 '13 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 '13 at 16:33
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 '13 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 '13 at 22:40
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 '13 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 '13 at 15:03
@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 '13 at 15:03
|
show 2 more comments
12 Answers
12
active
oldest
votes
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 '13 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.
– Dan Csharpster
Aug 14 '17 at 13:33
add a comment |
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.
That was it for me. Makes sense.
– Tom Haws
Apr 12 '17 at 7:44
add a comment |
Try using:
pushd \machineshare
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 \machineshare
to unmap the drive.
Reference: https://blog.adrianbanks.co.uk/windows/2007/03/08/accessing-network-file-shares-from-a-command-prompt.html
add a comment |
Another option is just to use the full network path, as Robocopy supports them. i.e. robocopy c:temp \serversharetemp
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.
add a comment |
echo Get-Date >> c:mount_nfs_log.txt
net use X: \sharefolder password /user:domainuser>> 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.
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.
– Tschallacka
Jun 1 '18 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.
– Ryan McGrath
Jun 2 '18 at 23:11
I didn't need the logging, so i just added acmd /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!
– Tschallacka
Jun 2 '18 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\ServerNameShareName
in this sort of logic. Additionally, this does not necessarily need to be PowerShell sinceNET 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.
– Pimp Juice IT
Jun 2 '18 at 23:26
Furthermore just to clarify, please note you could also useNET 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.
– Pimp Juice IT
Jun 2 '18 at 23:30
add a comment |
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 windowssystem32 as a security feature.
add a comment |
I had same issue trying to access r:/xxxfilename.txt with a windows mapped drive r:servershare 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 '16 at 11:37
add a comment |
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.
add a comment |
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. \ServerNamePath).
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.
add a comment |
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
add a comment |
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: "\xxxxxxxxx
cd /d Y:
net user /d Y: /Y
add a comment |
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 '16 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 '16 at 11:15
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f640962%2fwhy-cant-a-task-scheduler-job-access-a-mapped-network-drive%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
12 Answers
12
active
oldest
votes
12 Answers
12
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 '13 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.
– Dan Csharpster
Aug 14 '17 at 13:33
add a comment |
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 '13 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.
– Dan Csharpster
Aug 14 '17 at 13:33
add a comment |
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.
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.
answered Sep 6 '13 at 16:56
JackJack
1,06767
1,06767
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 '13 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.
– Dan Csharpster
Aug 14 '17 at 13:33
add a comment |
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 '13 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.
– Dan Csharpster
Aug 14 '17 at 13:33
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 '13 at 17:14
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 '13 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.
– Dan Csharpster
Aug 14 '17 at 13:33
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.
– Dan Csharpster
Aug 14 '17 at 13:33
add a comment |
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.
That was it for me. Makes sense.
– Tom Haws
Apr 12 '17 at 7:44
add a comment |
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.
That was it for me. Makes sense.
– Tom Haws
Apr 12 '17 at 7:44
add a comment |
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.
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.
answered Feb 23 '16 at 16:55
PeterPeter
282414
282414
That was it for me. Makes sense.
– Tom Haws
Apr 12 '17 at 7:44
add a comment |
That was it for me. Makes sense.
– Tom Haws
Apr 12 '17 at 7:44
That was it for me. Makes sense.
– Tom Haws
Apr 12 '17 at 7:44
That was it for me. Makes sense.
– Tom Haws
Apr 12 '17 at 7:44
add a comment |
Try using:
pushd \machineshare
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 \machineshare
to unmap the drive.
Reference: https://blog.adrianbanks.co.uk/windows/2007/03/08/accessing-network-file-shares-from-a-command-prompt.html
add a comment |
Try using:
pushd \machineshare
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 \machineshare
to unmap the drive.
Reference: https://blog.adrianbanks.co.uk/windows/2007/03/08/accessing-network-file-shares-from-a-command-prompt.html
add a comment |
Try using:
pushd \machineshare
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 \machineshare
to unmap the drive.
Reference: https://blog.adrianbanks.co.uk/windows/2007/03/08/accessing-network-file-shares-from-a-command-prompt.html
Try using:
pushd \machineshare
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 \machineshare
to unmap the drive.
Reference: https://blog.adrianbanks.co.uk/windows/2007/03/08/accessing-network-file-shares-from-a-command-prompt.html
edited Feb 18 '18 at 1:50
adrianbanks
7491620
7491620
answered Jul 14 '14 at 7:21
AnthonyAnthony
311
311
add a comment |
add a comment |
Another option is just to use the full network path, as Robocopy supports them. i.e. robocopy c:temp \serversharetemp
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.
add a comment |
Another option is just to use the full network path, as Robocopy supports them. i.e. robocopy c:temp \serversharetemp
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.
add a comment |
Another option is just to use the full network path, as Robocopy supports them. i.e. robocopy c:temp \serversharetemp
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.
Another option is just to use the full network path, as Robocopy supports them. i.e. robocopy c:temp \serversharetemp
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.
answered Oct 8 '15 at 18:31
KevinKevin
312
312
add a comment |
add a comment |
echo Get-Date >> c:mount_nfs_log.txt
net use X: \sharefolder password /user:domainuser>> 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.
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.
– Tschallacka
Jun 1 '18 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.
– Ryan McGrath
Jun 2 '18 at 23:11
I didn't need the logging, so i just added acmd /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!
– Tschallacka
Jun 2 '18 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\ServerNameShareName
in this sort of logic. Additionally, this does not necessarily need to be PowerShell sinceNET 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.
– Pimp Juice IT
Jun 2 '18 at 23:26
Furthermore just to clarify, please note you could also useNET 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.
– Pimp Juice IT
Jun 2 '18 at 23:30
add a comment |
echo Get-Date >> c:mount_nfs_log.txt
net use X: \sharefolder password /user:domainuser>> 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.
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.
– Tschallacka
Jun 1 '18 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.
– Ryan McGrath
Jun 2 '18 at 23:11
I didn't need the logging, so i just added acmd /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!
– Tschallacka
Jun 2 '18 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\ServerNameShareName
in this sort of logic. Additionally, this does not necessarily need to be PowerShell sinceNET 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.
– Pimp Juice IT
Jun 2 '18 at 23:26
Furthermore just to clarify, please note you could also useNET 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.
– Pimp Juice IT
Jun 2 '18 at 23:30
add a comment |
echo Get-Date >> c:mount_nfs_log.txt
net use X: \sharefolder password /user:domainuser>> 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.
echo Get-Date >> c:mount_nfs_log.txt
net use X: \sharefolder password /user:domainuser>> 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.
edited Jun 2 '18 at 23:11
answered Dec 11 '17 at 16:00
Ryan McGrathRyan McGrath
112
112
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.
– Tschallacka
Jun 1 '18 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.
– Ryan McGrath
Jun 2 '18 at 23:11
I didn't need the logging, so i just added acmd /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!
– Tschallacka
Jun 2 '18 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\ServerNameShareName
in this sort of logic. Additionally, this does not necessarily need to be PowerShell sinceNET 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.
– Pimp Juice IT
Jun 2 '18 at 23:26
Furthermore just to clarify, please note you could also useNET 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.
– Pimp Juice IT
Jun 2 '18 at 23:30
add a comment |
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.
– Tschallacka
Jun 1 '18 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.
– Ryan McGrath
Jun 2 '18 at 23:11
I didn't need the logging, so i just added acmd /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!
– Tschallacka
Jun 2 '18 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\ServerNameShareName
in this sort of logic. Additionally, this does not necessarily need to be PowerShell sinceNET 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.
– Pimp Juice IT
Jun 2 '18 at 23:26
Furthermore just to clarify, please note you could also useNET 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.
– Pimp Juice IT
Jun 2 '18 at 23:30
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.
– Tschallacka
Jun 1 '18 at 10:51
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.
– Tschallacka
Jun 1 '18 at 10:51
1
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.
– Ryan McGrath
Jun 2 '18 at 23:11
First time I've helped someone on stack overflow, glad I could help. Also, use "echo Get-Date" instead of what I had before.
– Ryan McGrath
Jun 2 '18 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!– Tschallacka
Jun 2 '18 at 23:17
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!– Tschallacka
Jun 2 '18 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
\ServerNameShareName
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.– Pimp Juice IT
Jun 2 '18 at 23:26
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
\ServerNameShareName
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.– Pimp Juice IT
Jun 2 '18 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.– Pimp Juice IT
Jun 2 '18 at 23:30
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.– Pimp Juice IT
Jun 2 '18 at 23:30
add a comment |
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 windowssystem32 as a security feature.
add a comment |
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 windowssystem32 as a security feature.
add a comment |
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 windowssystem32 as a security feature.
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 windowssystem32 as a security feature.
answered Sep 3 '14 at 10:58
user364486user364486
91
91
add a comment |
add a comment |
I had same issue trying to access r:/xxxfilename.txt with a windows mapped drive r:servershare 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 '16 at 11:37
add a comment |
I had same issue trying to access r:/xxxfilename.txt with a windows mapped drive r:servershare 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 '16 at 11:37
add a comment |
I had same issue trying to access r:/xxxfilename.txt with a windows mapped drive r:servershare 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.
I had same issue trying to access r:/xxxfilename.txt with a windows mapped drive r:servershare 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.
answered Nov 8 '16 at 20:53
ijimenez123ijimenez123
11
11
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 '16 at 11:37
add a comment |
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 '16 at 11:37
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 '16 at 11:37
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 '16 at 11:37
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered May 25 '17 at 9:38
user731960user731960
1
1
add a comment |
add a comment |
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. \ServerNamePath).
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.
add a comment |
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. \ServerNamePath).
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.
add a comment |
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. \ServerNamePath).
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.
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. \ServerNamePath).
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.
answered Dec 15 '17 at 20:43
Chris MatthewsChris Matthews
1
1
add a comment |
add a comment |
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
add a comment |
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
add a comment |
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
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
answered Aug 16 '18 at 9:56
Tom ArlethTom Arleth
1
1
add a comment |
add a comment |
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: "\xxxxxxxxx
cd /d Y:
net user /d Y: /Y
add a comment |
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: "\xxxxxxxxx
cd /d Y:
net user /d Y: /Y
add a comment |
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: "\xxxxxxxxx
cd /d Y:
net user /d Y: /Y
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: "\xxxxxxxxx
cd /d Y:
net user /d Y: /Y
answered Feb 15 at 11:47
AshishS1AshishS1
1
1
add a comment |
add a comment |
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 '16 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 '16 at 11:15
add a comment |
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 '16 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 '16 at 11:15
add a comment |
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.
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.
answered Apr 21 '16 at 20:30
user3062834user3062834
1
1
This does not answer the author's question. Please don't leave comments as answers.
– Ramhound
Apr 21 '16 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 '16 at 11:15
add a comment |
This does not answer the author's question. Please don't leave comments as answers.
– Ramhound
Apr 21 '16 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 '16 at 11:15
This does not answer the author's question. Please don't leave comments as answers.
– Ramhound
Apr 21 '16 at 20:55
This does not answer the author's question. Please don't leave comments as answers.
– Ramhound
Apr 21 '16 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 '16 at 11:15
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 '16 at 11:15
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f640962%2fwhy-cant-a-task-scheduler-job-access-a-mapped-network-drive%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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 '13 at 5:00
@SunWKim No spaces in either path.
– Craig W
Sep 5 '13 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 '13 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 '13 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 '13 at 15:03