How to safely change a backup task schedule?

"I pulled the old task script from a backup and have it working again.  I still want to change the schedule but I don't want to risk clobbering the task like I did yesterday.  Should I just try modifying the schedule again using the ATI backup definition procedure?  Should I manually edit the script?  I am not going to delete the old task going to delete the old task and create a new one."

I am confused by the last sentence. You are not going to delete the old task then say that you are. It occurs to me that the way to go forward would be to clone the existing task and then modify it to you new needs and see if the new task works. Modifying existing tasks on occasions produces unpredictable results (although ATI 2018 seems less prone to such behaviour).

Ian

I obviously repeated a couple of words.  I was trying to say I and not going to delete the old task and replace it with a new one.  I've already discovered that does not work.  And from what I've tried, either creating a new task or editing the old one seems to have the same results:  I am prompted for my Windows credentials.  Entering my Windows credentials does no good - the backup fails.  Entering the NAS credentials also does no good - Acronis (or perhaps Windows) rejects them with an error message.

Editing the script is not a solution either.  The scheduling information is not in the script.  I seem to be stuck with the old unchanged backup task.

Two thoughts...

1. Delete the task without removing the files. Then Add existing backup using the latest backup. Edit that task with your new schedule. This seems to have worked for me with similar problem when other approaches failed.

2. Just start over from scratch. Create a new backup folder on the NAS and a new task to use that folder. You can still keep the old backups.

Patrick, I would tend to go with Bruno's 2nd option, assuming that you have sufficient free space on your NAS, and go for a new backup task to a new target NAS folder, using the settings that you want to use.  Leave the existing, working task in place but perhaps change to being not scheduled while testing the new task.  If all is good from testing, then remove the old task settings and go with the new one.

I just ran an experiment on my network using the approach you are doing and found that my credentials were not accepted by ATI like you.  Strange as I never had this problem before!  So I opened Windows Explorer and attempted to logon to the NAS there and found that I could not do that either.  So I then logged into the NAS web interface using my web browser, went to my user account there and reconfigured the user password.  I did not change the password here but rather just reentered it in the fields required (both initial and confirmation fields).  I then went back to ATI and when prompted for credentials I entered the password and made connection without issue.

It would appear that a recent Windows version upgrade may have caused this issue although I have no solid proof of that!

When there appears to be a problem with credentials, first check the Credential Manager (Windows Control Panel) to see if things look good there. If not, you could see when it was changed and also try fixing it there .

Nothing changed in my case.  It was not an issue with Windows credentials but rather with credentials set for the user account on the NAS.  These Win 10 version upgrades are essentially a new install of the OS and change most everything including networking.  I suspect that Windows 10, after the upgrade, determined that the NAS was not a secure connection.  Authenticating the credentials on the NAS itself fixed that issue but like I say I have no proof of that.

EDIT:  I like your option 1 for Patrick here.  NAS credentials are probably not at issue here but something to look at if a task does not run as expected to a networked device.

I'll give #1 a try.  I'e never known what that "Add existing backup" was for.  Maybe I'm about to find out. :-)

I was going to say I had already tried #2, but the new folder I created was nested within the old folder.  I'll try creating a new top-level directory.  I could also try creating a new share on the NAS and use it, but I'd rather not.

I'm not sure when I'm going to be able to try these things since this problem is on my wife's laptop and she need to use it today.  Hopefully I'll get some time on it this evening.

Ok.  I think I've tried all of the suggestions and none of them worked.

1. I "changed" the NAS userid's password (entering the same password as before).  That change applied to all the following steps.
2. I deleted the old (working) backup task and used "Add existing backup" to create a new task.  All looked good until I tried running it.  ATI gave mew the old "Enter your Windows credentials" prompt which I took as a bad sign.  I entered my Windows credentials but the backup hung with the E01E50023 error.
3. I created a new share on my NAS and tried creating a task using the new share.  I did use the same NAS credentials (which have write access to the new share) because of the Windows restriction of having only one set of credentials for a given user/NAS pair.  That also gave the "Enter your Windows credentials" prompt.

Luckily I still had my backup copy of the working script so a copied it into the script directory and successfully ran it again.

I've read in numerous places that the prompt for Windows credentials is really supposed to be a prompt for the NAS credentials but the prompt rejects the NAS credentials as invalid.  That doesn't make much sense to me since ATI already has the NAS credentials; it was able to read the NAS directory with no problem.

I've noticed that the scheduling information is not in the script. Where does ATI keep this information?

BTW, AAP blocks my copying the backup script into the ATI script directory with no option to override it.  I had to turn off AAP in order to put the script in the directory.  Is that the way it is supposed to work?

Patrick,

Is this ATI install an upgrade from a previous version like 2017?  If it is this behavior may be a carry over from the previous version.  Unlikely but possible.

It would benefit you to contact Acronis Support on this as I think they need to have a look at this.  It may be necessary to uninstall 2018 completely using the clean up tool and install again fresh to fix the problem.

AAP is working correctly as it has self protection of ATI active at all times meaning that any change or modification outside of the GUI will result in blocking the action.

This is definitely an upgrade - 2015->2016->2017->2018.  I'm a bit hesitant to do the clean install because the old backup task works now.  It might not after a reinstall.

I will open a case with Acronis support but they have to "have a look at this" from a distance.  This is happening on my wife's laptop.  I have only sporadic access so I am not going to be able to give Acronis support remote access to it.

Patrick,

I understand your position.  Have you tried to clear out the network credentials in Windows registry on the machine?  I am pasting a snippet of kb58004 which details network credentials and how to remove saved credentials which will then make the program prompt you for them again and how to check the task script for credentials entries.  This might get things corrected for you:  The kb is for TI2016 but applies to TI2018 as well.

Where Acronis True Image 2016 stores credentials for accessing NAS/network shares

Acronis True Image 2016 stores credentials for accessing NAS devices in pairs: user name and password. Password is always obfuscated, meaning that only Acronis True Image software can read it properly.

Two processes access NAS: TrueImage.exe and TrueImageHomeService.exe (see https://kb.acronis.com/content/56697 for complete list of Acronis True Image 2016 processes).

When you configure/change backup tasks, browse to backups folder on NAS in graphical user interface, TrueImage.exe process is used and credentials are set to and retrieved from the following locations in Windows registry:

• Credentials for the NAS itself when using SMB shares are stored at HKEY_CURRENT_USER\Software\Acronis\Connections\smb\<NAS name or ip>
• Credentials for each top-level SMB share on the NAS that has been accessed at least once are at HKEY_CURRENT_USER\Software\Acronis\Connections\smb\<NAS name or ip>\<SMB share name>
• Credentials for FTP server are saved in a separate key HKEY_CURRENT_USER\Software\Acronis\Connections\ftp\<FTP server address:port number>

If you are running Windows session under a non-administator account, you would need to open registry editor "as administrator" to access that key: open Start menu, type cmd, right-click it, select "Run as administrator", type in your administrator password when prompted, and when command-line window opens, issue command regedit

When you save changes in backup task in graphical user interface, the program updates the registry cache and copies values from there to corresponding script file in C:\ProgramData\Acronis\TrueImageHome\Scripts. All the settings for given backup task, except schedule, are stored in one file with extension .tib.tis in that folder. You can open these configuration files with Notepad.

TrueImageHomeService.exe is the actual engine that performs backup, cleanup of old backups, validation, copy to second location, recovery and disk cloning (until reboot, if it is required). It takes credentials not from the registry, but from script file at C:\ProgramData\Acronis\TrueImageHome\Scripts. You can identify your configuration file by looking at 5th line of the file in Notepad - it will contain backup name. User name and password are stored in obfuscated form in between <volumes_locations> and </volumes_locations>

Known issues and solutions

Issue: Backups start failing after changing password for NAS account

Symptoms: backups start failing after you have changed password for your NAS account

Possible cause: password was not updated in Acronis True Image 2016. The program tries to access the NAS using old password.

Solution: close Acronis True Image 2016 window, clear old credentials by deleting registry key HKEY_CURRENT_USER\Software\Acronis\Connections\smb, open Acronis True Image 2016 window and edit your backup task, re-select your NAS folder as destination for storing backups. The program will detect that registry cache is empty and will ask for new credentials. Enter your NAS user name, new password and run backup task. Software will recreate registry cache and update corresponding backup configuration file in C:\ProgramData\Acronis\TrueImageHome\Scripts

Issue: Different sets of NAS folders/shares are shown in Windows Explorer and Acronis True Image 2016

Symptoms: you see different set of folders/shares on your NAS when you access it in Windows Explorer and in Acronis True Image 2016

Possible cause: you may have used different credentials when connecting to NAS in Windows Explorer and in Acronis True Image 2016. NAS may display only those shares/folders that current user account is allowed to access.

Solution: see what user accounts were used to access the NAS in 1) Windows Explorer: open Control Panel - User Accounts - Credentials Manager - Manage Windows Credentials and 2) Acronis True Image 2016: see registry key HKEY_CURRENT_USER\Software\Acronis\Connections\smb\<NAS name or ip>\<SMB share name>. If you see different user names, then you can delete saved credentials in Windows Credentials Manager and/or Acronis True Image (key HKEY_CURRENT_USER\Software\Acronis\Connections\smb), restart Acronis program and use only one account while browsing folders on the NAS.

Issue: Backup to NAS fails due to wrong credentials while NAS could be browsed successfully in software`s graphical interface

Symptoms: you can browse your NAS contents successfully in Acronis True Image 2016 window, but backups (both manually started and scheduled) are failing with an authentication error.

Possible cause: password was written incorrectly into backup configuration file

Solution: copy obfuscated password from the registry cache HKEY_CURRENT_USER\Software\Acronis\Connections\smb\<NAS name or ip> into backup configuration file at C:\ProgramData\Acronis\TrueImageHome\Scripts. Save changes in the file, run the backup and see if it now succeeds.

Yup.  I've deleted the \Acronis\Connections\smb\ registry records several times during my trials.  However, the fact that the restored old script works without touching the registry makes me think it is not really a credentials problem.  The registry records that get rebuild work with the old script even when they get saved when running the new (failing) script.

Patrick wrote: "This is definitely an upgrade - 2015->2016->2017->2018."

This is a case where I agree with Bob that a clean install of ATI 2018 is recommended given the number of previous software versions. 

It is also an easier task to undertake given the new options provided in 2018 to backup and import back your task configuration settings without needing to save the contents of ProgramData folders.

An obvious safeguard would be to make a full backup of the OS drive before doing an uninstall, running the cleanup tool and reinstalling, so that in the worse case, you can get back to where you started from!

Patrick, I'm curious about the fact that simply restoring the script file from backup works OK. Would it be possible to compare a script file when you've made a change and it fails with the backed up script that works. Being text files, it should be easy to see what may be different in the volume information. Might give a clue.

I will get to the comparison soon but I have some new, puzzling information first.  I deleted the old ATI and did a clean install, tested the old script to make sure it still worked.  Then I made my changes and it failed again.  (Boo!  Hiss!) 

The changes I made (each time) are

1. change from daily to weekly
2. change incremental scheme from full backup every 6 generations to every 5 generations
3. change the saved version chains from 5 to 2
4. add a pre-execution command

But I noticed that after the clean install that the schedule was no longer "daily".  It was "Do not schedule".  So I restored the old script and change the schedule to "Weekly".  I got no prompt for my Windows credentials when I made that change so I tried manually executing it.  No problem ... except that it's now taking a full backup so I have to wait for my next test.  When it is done I will try changing the backup scheme.  If that works I will try adding the pre-execution command.  When I find the offending option I will then compare the scripts.

Update: 

The backup completed so I changed the backup scheme - 5 generations, keep 2 chains - and it also worked.  (And it is taking another full backup.

It looks like the culprit is the pre-execution command.  But several days ago I created another backup task using that same command and it runs with no problem.  I'm confused.

Patrick...I have been following this thread with interest as I had something similar happen several months ago.  I have not responded earlier since I could not remember all of the details of my issue and did not have any recommendations...until now. 

Your comment: "It looks like the culprit is the pre-execution command.  But several days ago I created another backup task using that same command and it runs with no problem.  I'm confused."

Background...I have developed an app which is a subset of the MVP Log Viewer (which I also developed).  The new app is designed to automatically delete old log files.  The user would set the "age" of log files in days (3-10) and the app would automatically delete logs that are older than the "age" set by the user.  The app will only delete log files when it is run as a pre or post execution command.  If the app is run stand alone, it brings up the menu where the user can set the "age" of log files to delete.

The app works great when run in conjunction with a backup to a local disk.  However, when run in conjunction with a backup to my Synology NAS, sometimes it would cause the backup task to start failing.   Pretty much the same as your problem. 

For this reason, I did not release the app to all ATI users.  For the MVPs, the latest version is available in the MVP section.

My conclusion is that the pre-command you are using, in-fact, is the culprit.  

My recommendation is to stop using the pre-command on tasks that go to your NAS.

For our information, can you provide the guilty pre-command?

So, I will now run some tests and see if I can duplicate the problem.  

I have added my Log File delete app as a pre command to one of my tasks.  So far, I am unable to duplicate the problem.  However, reading the ti_demon log file,  it includes information that the child command exited with code '0'.

Patrick, can you post the ti_demon file for a task that fails?

There are some other things that I plan to try to duplicate the problem.  Will report back any findings.

FtrPilot,

I don't have access to the laptop in question right now.   I've attached a log file from the System Report I generated several days ago.  (it's the raw log.  I tried point the Log View at it but that didn't work.)  The command seems to have executed with no trouble.  The command itself does not reference the NAS; it is just a .bat file on the C: drive that looks at a .txt file on the C: drive.

I don't think the command itself is a problem.  I think the act of adding the command to the backup definition does something bad.  Just last weekend I added the command to two other backup definitions - one and FTP backup to a (different) NAS; the other a backup to an external drive.  Those backups still work fine.  But adding the command to a backup using an SMB connection to a NAS seems to be problematic.  I'll do more diagnosis the next time I have access to the laptop.  Maybe I will also try reproducing this on my "test" PC.

Patrick,  thanks for the info.  I agree that the issue is related to smb.  I have not tested ftp, but I have tested and run to local disks and usb disks without issue.  The only time it causes a problem is backup to my NAS using an smb connection.

In my effort to duplicate the problem, I have be unable to succeed when performing the backup by hitting the backup now button.  I am going to wait until the next scheduled backup occurs and see if that causes the failure.

I plan to run some additional tests later this afternoon and will report back.

I have also downloaded your log file and will see if I can get the next version of the log viewer to display system report logs.

Regards,

FtrPilot

I have run several additional tests and have been unable to duplicate the problem.  Will report back if anything changes.

I've been watching this thread with interest. Looking at Patrick's log from yesterday, it still seems the problem is in trying to access a file with a name ending in _v11.tib whereas it probably should be _v1.tib. Am I correct about this? Although the specific error differs from my issue, both issues seem to be a result of the bad file name being referenced by the program.

I have referenced this thread and Patrick's prior thread on my support case (03288103) but all communication with Acronis support seems only in being able to get the backup working on my system. I do not know to what degree they may be looking at a programmatic problem.

I tried to relate this problem to a specific Windows 10 update, but on one machine it occurred before the latest update and on the other machine after. I also have a pre-command on the job, although the command does no file access; it just checks the date to allow or deny the backup to run. And my problem only fails when run under schedule, not when manually started.

Our symptoms are quite different but I agree that the _v11.tib is common to both problems and that this must be a programming error.  But I suspect there is an earlier problem getting us into that code path.  Does Acronis prompt you for your Windows credentials?   I suspect that's another part of the bug I've run into.  Soon I will try reproducing this problem on another computer - one where I don't a Windows password - and will see what happens there.

I submitted a problem report about this to Acronis support several days ago and have received nothing other than their automated reply.  Maybe they are short-staffed.  (Or maybe I've gotten a reputation of being a "difficult" customer.)

Well, I've succeeded in reproducing the problem on my "test" PC and I think this should really go back to  my "Problem backing up to NAS" thread (but I'll keep it here for now.

The problem does not happen with a "Files and folders" backup, just with a "Disks and partitions" or "Entire PC" backup.  And the prompting for Windows credentials is not a symptom; ATI apparently does that if there are Windows credentials defined.  (BTW, there are only local accounts on all 3 of my computers.)

I repeatedly successfully created backups on the NAS drive for folder backups and repeated failed to create Entire PC backups or Partition backups. 

I did not try any backup without a pre-execution command.  I'll try that later.  I already have a Partitions backup to the NAS defined on the test PC and I think it has a pre-execution command.  I haven't tried running that backup for many months but I know it used to work.

Update:
The old backup task did not have the pre-execution command.  I didn't try executing it as it was because a multi-partition backup to a NAS takes a long time.  I added the pre-execution command and the task failed with the expected failure.  Removing the command did not help - it still failed.  Deleting and redefining the task without the command did work.  The backup is currently running.  (I tried defining it using "Add existing backup" and it failed but that may have been something I did wrong.)

Patrick...thanks for the update.  I also have some news to report.

Reference my attempt to duplicate the issue above:  The task that I edited to add a post command ran successfully until last night.  Prior to it running, I created a new task (disk & partitions to a different account on the NAS).  This new task did not have a pre or post command, and it ran successfully.  Then the task with the post command, at the next scheduled run, failed.  ti_demon log attached.

This morning, I noted the failed task and looked at the script file and the login information in the script file look OK.  I tried to run the task, hitting the backup now button, and the task failed again, with the same error message.

In my case, creating a new task caused the existing task (with a post command) to fail.

I will see if I can duplicate the error.

Patrick's Quote: "And the prompting for Windows credentials is not a symptom; ATI apparently does that if there are Windows credentials defined"

True Image does not use Windows credentials.  It does not use or store the NAS file location as a mapped drive.  It stores the file location using the NAS name or in some instances the NAS IP address.

Personally, I don't store any NAS credentials in Windows credentials and I don't map any NAS shared folders.

FtrPilot, I notice that in your log you are getting a "Cannot access backup file ..." error.   I would guess that's a different problem than the one resulting in "Please close the application ... _v11.tib" error.

Regarding the Windows credentials prompt, I don't think ATI is directly doing this at all.  I think ATI is changing something that Windows considers protected by my credentials.  (I suspect it is happening during the registry update, but that's a guess.)  The prompt does not happen on Windows accounts where I don't have a password; it does happen on accounts where I do have a password.  Yesterday on my test PC I created an account with a password.  Using that account I would get prompted for Windows credentials when I finished saving my backup-to-NAS task.  Updating that same task using my regular account (with no associated password) I got no prompt.

All,

I have been doing some research on this issue and may have a solution.  This has about a 50/50 chance of working so be forewarned! 

First, you need to think of your NAS as a computer because for all intents and purposes an NAS device is in fact just that.  Why? Network connected computers are network connected devices period no matter what the device is.  It is simply the fact of how they are connected that makes the distinction.  Additionally, the consumer NAS devices of today all use a Linux based OS for WEB-UI management and connection purposes.

Another thing that you need to think here is that in all cases with networked computer NAS devices is that you are Sharing data between the host (your PC) and the NAS device.  So file sharing needs to be set correctly for things to work as intended.   User permissions are also a piece of the puzzle here and can be at issue which I believe is the possible case here.

I suspect that changes to a task once created will trigger the need for network authentication thus the reason for the prompt for credentials appearing.  If you are not prompted for credentials that is a problem because you should be!  When the credentials prompt appears in this scenario of backing up to an NAS no matter if the prompt is for Windows credentials or Acronis credentials what is needed are the credentials for the destination network share.  When you changer or modify a backup task you should edit/reenter the network share credentials to establish connection to the share.

Below is a snippet taken from the TI 2018 user documentation PDF file which describes Authentication settings for networked computer devices:

3.5.3 Authentication settings.

If you are connecting to a networked computer, in most cases you will need to provide the necessary credentials for accessing the network share. For example, this is possible when you select a backup storage. The Authentication Settings window appears automatically when you select a networked computer name.

If necessary, specify the user name and password, and then click Test connection. When the test is successfully passed, click Connect.

Troubleshooting

When you create a network share that you plan to use as a backup storage, please ensure that at least one of the following conditions is met:

 Windows account has a password on the computer where the shared folder is located.
 Password-protected sharing is turned off in Windows.
You can find this setting at Control Panel —> Network and Internet —> Network and Sharing Center —> Advanced sharing settings —> All networks ---> Turn off password protected sharing.

Otherwise, you will not be able to connect to the shared folder.

PLEASE NOTE THE LAST SENTENCE HERE.

Some things I have found:

When Windows 10/8.1 does these periodic version upgrades there are always a large number of settings that are changed from what they previously were prior to the upgrade.  The Control Panel sharing settings I have found changed after an upgrade on a few occasions.  Check yours!

When you change a backup task in any manner you need to reenter the password for the share connection.  DO NOT click on the Test Connection button without entering the password anew.  This will fail the connection test as the password will be incorrect.  You must clear the password field in the credentials prompt and reenter the correct password for the connection to work.  If you do not do this then the current correct password will be overwritten by an incorrect password.  This is part of Windows network security not Acronis True Image.  Because True Image uses Windows rules in encrypting Internet and LAN passwords is cause of the behavior of incorrect passwords. 

I have found numerous discussions on the internet about encrypted passwords and how Windows handles such.  In all cases where passwords are encrypted when Windows or other applications prompt users for networked credentials what is shown in the popup prompt as a saved password will be incorrect.  You should note that what is displayed are either 9 or 12 digit (dots) for the password.  Most users have 6 or 8 digit passwords so this should be your clue that things are amiss.  If you do not clear the password field and reenter the correct password for the network share in this prompt box the connection attempt will fail.

I also note that in Randy's log posted above the errors shown including the Windows error all indicate a bad username password combination.

Enchantech  said " When the credentials prompt appears in this scenario of backing up to an NAS no matter if the prompt is for Windows credentials or Acronis credentials what is needed are the credentials for the destination network share. "

Unfortunately, in the cases I've tried, NAS credentials are rejected; only Windows credentials are accepted.  Also, if no pre/post-command is involved in the task definition, all is fine one the Windows credentials are entered.  (The NAS credentials had been entered earlier in the definition process if ATI did not already have the credentials in the registry.)  On the other hand, with pre/post-commands in the definition the task fails regardless of the credentials entered.  (There won't even be a prompt for them if the Windows account does not have an associated password.)

I don't recall whether or not I've tried doing a connection test without entering the NAS credentials but I've never seen the connection test fail (with SMB connections).

I believe everything you wrote but I'm not sure it applies to this particular problem.

I have experienced what Patrick has regarding ATI asking for Windows credentials when editing a task...I was confused in my earlier remarks regarding credentials.

I also have some additional data and screen grabs.

For me, the problem occurs when editing a task that has a pre or post command and there are more than one task in the gui.  Somehow, ATI gets confused and combines information from 2 of the tasks.

In the above screen grab, the backup is a disk mode backup of c drive and d drive with a total of 450Gb.  The graphic display of the data shows the data to recover is 8.5Mb and is from the task above titled 'FileTest'. 

Then when asking for credentials, ATI is asking for 'FileTest' credentials, not 'AsusROG_318a' credentials.

Definitely a bug in ATI code.

Guys,

I have also experienced ATI asking for Windows credentials except that in my case the issue was with TI 2017NG.  I worked with Acronis R+D to remedy the issue.  Several attempts at building new versions of TI were necessary to finally fix the issue and that fix was distributed in a subsequent version release

Did either of you upgrade your 2017NG versions to build 8058?  That version had the fix above.

I think you can test your installs to see if they behaved as mine did.  If you can, I think that might prove that the problem exists in certain upgraded products.  

Here is how to test:

You need to start with a full Windows shutdown and restart.  From an admin command prompt type Shutdown /r  

This will close all applications, sign out the user instance, and shutdown the PC.  The /r switch will restart the PC once the shutdown completes.

After the restart immediately open TI and attempt to navigate to the offending network share on your NAS.  If you can do that successfully without being prompted for credentials then you do not have the same issue as I had.  If you are prompted for credentials enter them (this should be a Windows credentials logon request).  At this point your connection should fail to connect. 

Now close the TI application and open Windows Explorer.  Attempt to navigate to the network share (at some point you will be prompted for credentials, again this is your Windows credentials for the network).  Enter the credentials and you should be granted access.  If this is successful, close Explorer and once again open TI.  Attempt to Navigate to the network share again.  You should have no problem doing so and should not be asked (prompted) for credentials. 

If that all proves correct in your case then I believe that my experience with this and yours are the same.  I would also be willing to bet that your installs either carried over the problem from previous versions or possibly you did not upgrade TI2017 to the last version release prior to upgrade to TI2018.

I have Network password protected sharing OFF on this PC.  I do not have a Windows user account on the NAS device in question here.

Looking forward to your replies!

Randy, your screenshot shows an ATI credentials prompt whereas Patrick seems to have issue with Windows credentials prompt.  Will be interesting to see what each of you finds in the above tests.

Bob,

There are multiple issues within this thread.  The point that I am trying to make is that when editing a task to change the schedule, the task subsequently stops running with login errors.  If you look at my first screen grab, it shows the correct source & correct destination, but the visual depiction of the data shows only 8.5Mb.  The visual depiction of the data is from the task labeled 'FileTest'.  Then, when the backup now button is hit, the task fails with the "Please ensure that you entered the correct credentials for the network share." error message...with the option to input the correct credentials.  Then the credentials popup shows the incorrect path.  The path shown is for the 'FileTest' task.  So, the task that was edited will not run...somehow, it is corrupted.

Further testing shows that the Windows Credentials will popup when adding or editing pre/post commands.

Also, if you edit the schedule of a task that contains pre/post command, then the Windows Credentials also popup.

I'm confused about the reference to 2017NG.  I don't think I've ever had (or wanted) NG.  (Actually, I don't know what is implied by "New Generation"  except that the new log format is referred to as NG.)  I'm running ATI 2018 build 10640.  On one of my computers I've done a complete uninstall and reinstall; it still has the problem so it's not a leftover from a previous release (unless I missed a registry record somewhere.)

Enchantech said: " After the restart immediately open TI and attempt to navigate to the offending network share on your NAS.  If you can do that successfully without being prompted for credentials then you do not have the same issue as I had.  If you are prompted for credentials enter them (this should be a Windows credentials logon request).  At this point your connection should fail to connect.  "

I admit I have not followed these instructions, I think I have evidence you and I are talking about different problems.  In my case ATI does not require my providing the NAS credentials unless I delete the ATI connection records from the directory.  What I see I think demonstrates this is not a NAS credentials issue:

1. I create a new "Entire PC" or "Disk and partitions" backup with destination on a NAS.  If ATI has not been given the NAS credentials previously I am prompted when defining the destination. I include a pre/post-execution command.  If I am on a Windows account with a password I will be prompted for my Windows credentials when I am done defining the task.
2. I run the task.  It fails.
3. I delete the task and re-enter it without the pre/post-execution command.  I am not prompted for NAS credentials because ATI has previously saved them in the registry.  I am once again prompted for Windows credentials if my account requires a password.
4. I run the task and it succeeds.
5. I again delete and re-enter the task definition (including the pre/post-execution command) again just to be sure.
6. I run the task and it fails.
7. I delete the task again and define a "Files and folders" backup to that same NAS.  I include a pre/post-execution command.
8. I test the task and it succeeds.
9. I define another task - Entire PC, destination on a local drive, with pre/post-execution command.
10. It succeeds.

I am convinced that this problem has nothing to do with Windows credentials and has nothing (directly) to do with NAS credentials.  The saved credentials (and everything else) work just fine for a "Files and folders" backup (with or without a pre/post-execution command).  And everything works fine for "Disk and partitions" or "Entire PC" backup tasks that do not include a pre/post-execution command.

To summarize:  my backups fail it the task definition includes

1. a full partition source - either Entire PC or Disk and partitions
2. destination on a NAS
3. a pre/post-execution command.

If a successful task with the first two conditions gets pre\post-execution command added the task will now fail.  Removing the command will not help.  The task has to be deleted and re-entered without the command.

I understand that these symptoms may not match problems anybody else is having but they are consistent across all 3 of my computers.

Ok guys,

I was finally able to reproduce the failure where the "Please close the application ... _v11.tib" error was produced. 

Here's how I did that.  I selected an existing full OS disk unscheduled backup task and added a pre-command simple batch script to check the OS disk size.  This was so that I could see the command prompt run and insure the pre-command executed when the task was run. After the changes I ran the backup task and it produced the error.

I decided to try the Ignore option in the error.  After a couple of minutes the same error reappeared.  So, I decided to select the Browse option to select another folder.  It just so happens that I had a folder named Test without anything in it in the same share location but outside of the original path.  So the path is like this:

\\devicename\my backups\Desktop\full_b1_s1_v1.tib (path before modification of the task)

\\devicename\my backups\test\full_b1_s1_v1.tib (new path after selecting Browse)

Selecting the new folder did the trick and the task is running as I write this.

This may not be the way that users would like this to work I agree.  What I can say is this.  In past versions of ATI changing tasks configuration often caused unexpected results.  This may be related to that issue however, it is now possible to change other parts of a existing task without issue so I am not sure about this.  Windows Security prevents more than one connection to the same network share during any one computing session.  This seems more likely the problem here.  I say that because once a task is defined and run the connection credentials are remembered.  If we then change the task and do not change the destination share location Windows could/would/may deny access under such a security policy.

So I am not sure which is at fault here but it does appear that when adding pre/post commands to existing tasks you must also change the destination folder location to achieve success.

:)

Hmm.  I'll have to try that.  I could have sworn that changing the destination folder did not help.  In fact, in one test I created a new share on the NAS (but accessing it with the same credentials) and it still failed.  But I was flailing around in my tests then so really have no idea what I actually tried.

Enchantech said:
" Windows Security prevents more than one connection to the same network share during any one computing session.  This seems more likely the problem here.  "

I thought the restriction was one set of credentials per Windows user / NAS share pair.  If the same userid/password on the NAS is used to access multiple folders, shouldn't Windows allow that?  I'm too tired to test that right now; I'll try tomorrow.

Well done Enchantech!

Question...did you get a request for Windows Credentials after you added the pre command?

Also, how many tasks do you have in the ATI gui?  In earlier testing, I was able to make multiple changes to an existing task (without errors) if there was only one task in the gui.

I will see if I can duplicate your test.

Randy,

No, I did not get a Windows credentials request.  I'm glad you asked because I was in a bit of a hurry last night and I see now that I left out the credentials part of my test.

That's huge because what I did/didn't get explains a lot!  My apologies for the omission .

After I added the pre-comand I got a few seconds of screen blur while the command was added to the task and nothing else.  I expected a credentials prompt but none was to be had.  So I decided to force the issue by selecting a new destination folder which I planned to do anyway.   So I created a new folder under the folder which contained the original .tib file of the task.  As expected when I clicked on the original folder I was given an ATI credentials prompt.  I clicked in the password field, removed what was in the field, and typed in the correct password which was accepted.  I then added the new folder and selected it for the destination .

With that done I ran the task.  The command prompt window flashed on the screen followed by the calculation phase.  After a couple of minutes I got the V11 error which I posted last night .

I think this shows that when you are presented with the ATI credentials prompt you must clear the password field and reenter the correct password because of ATI encrypting the password .

Further, the V11 error is ATI  objecting to there being two like named files in the same folder structure and wants itself to close so the requested action can be completed, a bit of irony there!