Backup fail due to Network share not being found (may not be share relatated it now seems)

Hi mgrobins,

Question, are you using the same network path for the new backup scheme with 2018 that you used with the 2016 version?

If yes, is there another old backup .tib file in that folder from 2016 with the same name as the backup .tib file of your new scheme that fails?

Can you post a screenshot of the error that comes up where you have tried the retry/stop/browse actions?

Hi :).

Sorry forgot to point out I am using a new file name... one of the first things I confirmed!

I have a SS from when I originally had the issue thankfully....

image attached :D

The error you are getting is True Image complaining that it has detected a like named file within the share folder structure.  I confirmed this true just a couple of days ago as posted in this THREAD

The error is telling you that the backup file location is already open and in use and to gain access you need to close the application that has it opened which in this case is TI itself. 

You will need to select a different folder or create a new folder for the backup.  This new folder cannot be nested below the current folder that TI is objecting to else the same error will be given.

Are you saying that it kicks up an error about naming even though there is no file of the same name present or that I need to double check there is not one already in there?

I will reinstall if it's likely my error and retry but if what you are saying is there is a bug in what it's doing then I'll leave it for now.

It is not a bug.  It is Windows Security Policy.  For networks there cannot be more than one authenticated connection to share during any one computing session.  So Windows determines that your existing NAS share is an open authenticated connection when you drill down to it in the TI app.  With that share open TI will allow you to configure a new backup but when you select to run the task you get the error because TI thinks that the backup file is already open.

At this point I am not sure if anything can be done about that behavior due to Windows Security Policy rules.  So the workaround is to setup the new backup to a different Parent folder which should succeed.

ok I think I get what you are speaking about. We actually discussed this some months back in another thread I started.

This backup should still work when I reboot or start windows and run backup by script. At that point there is no conflict. It's not working.

I think the error you were reproducing in your other mentioned thread is different to mine.

I reinstalled TI 2018, created a new Share with the correct access credentials.

Created a new backup plan and it still comes up with the same error.

Can you test this by using the name of the NAS rather than using the IP address for the connection?  That should be considered a different connection.

Also, in your screen shot, is the file name correct with the _v11.tib at the end - we have Bruno reporting a bug where ATI is looking for a _v11. file that has never existed?

mgrobins...From your screen grab, it appears that you are 'browsing' to select the backup destination.  Have you tried using the NAS selection option?  I am not sure if this will fix the issue, but it might.  I have been using ATI 2018 with my Synology...with much better success than ATI 2016.

In re-reading mgrobins screen grab, it looks like this is not a NAS login/credentials problem.  ATI is looking for a file that doesn't exist.

This looks like another occurrence of the _v11.tib error. I have just created another thread for this issue in hopes that it can consolidate the information and hopefully lead to a solution.

I just posted to Bruno's new thread.  Yes I agree this is not a credentials problem, never said it was.  In this instance it is simply the trigger for the error and I think Windows Security Policy plays a role here as well but just in this scenario.

mgrobins, how is your NAS connected to your PC?  Is the connection self powered or does it use power from the connecting port? 

Thanks folks - I'll have a read of Bruno's thread too.

I have 2 network interfaces running on my setup at home, which have been working perfectly with TI 2016 and not TI 2018.

LAN1: 1GBe:  192.168.1.x   connected to gateway and internet. NAS 192.168.1.x

LAN2: Direct 10GBase-T connection NAS and Desktop  192.168.0.x  no gateway.

The 10GBe connection does not show up under "NAS" or "network", thus I browse to it. It is discovered correctly.

I'm not sure what you mean by self powered? The connection to the NAS is via standard ethernet hardware. The connection is sound and works in all other instances. Checks out just fine with iperf  or other general use.

Works perfectly with TI 2016 browsing to \\192.168.0.3\  which is my NAS.

EDIT:

I found I can get a backup working to my NAS - only if I use an existing backup.

1. add existing backup (browse to \\192.168.0.3\   ...)

2. reconfigure (didn't even touch credentials).

3. backup .... and it works. Same settings as I normally use and my normal directories.

NEW Backup to NAS will still not work.

Thanks for working with me on this. I'm not getting far with support.

mgrobins,

Thanks for adding the details of your network setup.  It is not common that users have a network setup such as you do with two NICS. running independent of each other.  I can tell that each network is on a different subnet and this may be the reason for your problems.  The trick is to get discovery and of course traffic working between the networks.

What are your connected devices using as a subnet mask?  Typically this is setup as 255.255.255.0.  If yours are set this way you probably should set it up as 255.255.224.0.  This would give you a wider range of subnets to work with which would all be able to pass traffic to each other.  You would need to set all device connections up like this for it to work properly.  I would think that this would allow TI to discover your 192.168.0.3 network which in turn should help in getting things working.

TI works on an existing backup and not a new one. A network level issue would not work for either - unless it is internal to TI 2018 I would think... but the nics are co-joined by the machines themselves so it bears investigating.

The 2 networks have no physical overlap. The 10GBe setup is basically a SAN. Using shortcuts via IP rather than device name ensures that the appropriate pathway is used. I don't know what's happening behind the scenes with that though.

I previously did run multiple subnets over one LAN as I had a 10GBase-T switch in the mix. Having removed that and creating physical separation the subnet mask should not be relevant but I'll have a play with it anyway just to make sure either machine isn't reading both NICs as a single entity or doing something silly.

The reason network discovery is not working reliably is that MS removed SMB 1 support in the Fall Creator's Update, along with NETBIOS support. MS want people using mapped shares as stated in their release. Personally I use a shortcut on my Quick Access to my NAS as a Network Device not as a mapped drive which is more convenient for my needs over having multiple shares mapped.

EDIT1:

changed subnet masks and now can run a new backup task. 

l returned the subnets to 255.255.255.0 just for completeness and verified if problem is back as I can't work out how this is a problem for 2018 but not 2016 or any other software I run. Especially since 255 means that digit is being compared for exclusion therefore the '0' and '1' nets should be seen as different by any program!

Result: both new and existing backup tasks to the NAS are functioning.

So... at this point I'm stumped as to what was causing it or how to reproduce it. My network configuration is the same, software is the same and network settings the same. Machines were rebooted etc and problem was still present. Now it's gone.

Almost makes me wonder if it's something TI is recording that was out of order and has now been corrected.

The fact it persisted even after removal and re-installation around a functioning install of TI 2016 leaves me stumped too.

Did you reboot after changing the subnet back before testing for the return of the problem?  

Of course.

Hello mgrobins,

Could you send us a feedback from the product and check the box "attach a system report" (do not attach the report manually - it will be rejected due to large size)? I'll pass the logs to the developers. Thank you! 

I am no expert with networking but it is my understanding that the subnet mask change I suggested enables your ability have the 2 networks you have pass packets between them because it allows for the 192.168.1.0 network to find the IP addresses of the 192.168.0.0 network in the absence of a router/bridge or an NAT.  One of these has to be in place to resolve addresses in Private class C networks which yours is.

When you changed that this allowed the backup to succeed.  It also allowed True Image to create a credentials location key in Windows registry.  I would say that the registry entries were missing before and that is why you could not complete a backup task.  Now that you have this information saved in the registry the task continues to work.

Interesting theory... though I see some potential flaws:

1. the old backup worked to the same destination where a new one would not. 

2. Given there are two physically separate LAN's I would have thought the subnet mask should not be relevant to this circumstance.

3. I had manually confirmed the presence of correct credentials in the SMB folder, and the script file at a much earlier stage of troubleshooting.

I'm not sure enough myself to know the answer. 

If temporarily changing the subnet mask allowed TI to register information and then function after restoring and "incorrect" network configuration... well that points to an issue with TI. Every other program is robust enough to work with what I have in place.

Is network information stored at more than one location?

I posted on another forum I frequent for networking to seek some advice on the subnet masks... it's important to know anyway (I did do reading on this when establishing the new 10GB connection... I *think* it is fine).

I have no doubt your connection will function as independent networks sure.  The point I am making is that they exist but as is I don't think they are "aware" of each other.  In other words they cannot pass data between them.  Have you tried this to see?   I have never had a setup like yours I cannot say for sure.  It does make sense to me however that this may be the case.

I can certainly understand why you might want this independence in place.  Because Private networks need a gateway to public networks without that they have no access to the vulnerabilities of a public network as it were.  

I am guessing of course on TI and how it works here.  What I do know is that TI uses the Bonjour service for certain network functions.  Possibly there is something there that would further explain this.  I suppose it is possible for that service to store network information.  You can read the text documents for Bonjour by navigating to C:\Program Files (x86)\Bonjour\en.lproj\.  You will find an .rtf file there.

It is widely known that the Bonjour service provides discovery services, how they work I have no idea. 

Thank you Ekaterina,

I have submitted feedback including the system report (I assume ticking the box generates one and adds it automatically?). For completeness I included a link to a system report from when the backup would not work so staff can see what may have changed.

Enchantech I can see your direction with this and I agree it is potentially a source of the problem.

Advice I have is that given the physical separation of the two networks the subnet masks are fine. 

If TI is using a windows service to determine pathing then I think that needs correcting where a specific path is provided. I could see using the name of the NAS being a problem as that then requires resolving ....but I'm using an IP. 

The only NAS connection that shows in the network field on TI is the 192.168.1.x  one.... not the 10GBe direct link.

mgrobins,

Right, and therein lies the problem in my perspective.  Again, your setup is not typical of most users.  I have machines with dual NICS so if I can find the time I am inclined to create a setup like you have and see what I can make or break! 

Hopefully I can do that soon and also that Support can give some direction here.

/sigh .... well this is starting to tick me off now.

Found this morning last nights scripted backup to NAS failed as it "could not write to the destination".

Retry and it is producing the same errors as before. The only way I could get it running again was to add the old existing backup and reconfigure to run again.

I need to re-check all of my steps again but this is getting ridiculous.

Ekaterina, my original support case is being closed I believe or at least is done technically as I thought a resolution had been achieved (though no actual solution). Is it possible to have my feedback added to my support ticket?

E-mail header: [03304817] TI 2018 "Cannot access Backup Share" (network)    [ ref:_00D30Zcb._50050142p3L:ref ]

EDIT:

Troubleshooting steps:

1. linked and reconfigured existing backup task with normal credentials and destination. This appears to work again.

2. I'll run this on my normal backup schedule and see if it continues or plays up. Will report back tomorrow or day after as it goes.

Currently have little confidence about this :/

Incidental Information....

My backup uses 2 scripts and the following setup:

1. NAS powers on 0200h daily

2. NAS wakes PC (WoL function)

3. Acronis scheduled to run daily backup on PC (local destination drive), then runs  batch to activate 2nd daily backup task. 

4. PC backup to NAS is performed. Credentials are an account on NAS that is only one with write privilege for destination. 

5. Acronis calls batch file to shut down NAS and PC once completed.

My reasoning for this structure is that the NAS backup destination is not able to be written to or interfered with in general daily use of the PC. Goal was to preserve backups from interference by virus (especially ransomware or other crypto virus).

mgrobins...This is just a guess, but I am wondering if this is related to Windows Security Policy stated by Enchantech above:

https://forum.acronis.com/comment/446315#comment-446315

When the NAS wakes the PC, is this done from the same NAS account that ATI uses for the backup?

It's done by magic packet directed by the MAC address on the NIC. Nothing to do with windows at that level beyond power states and wake states.

The post you referenced presupposes that TI is open and accessing the share already - which occurs when defining and working on the scripts but should not be the case when a script is simply called to initiate backup. A useful point when troubleshooting or testing I think (If it is actually a functional problem with TI's design)... but not what I think is at cause here.

TI 2016 working always, ant TI 2018 being flaky suggests 2 potential causes:

1. TI2018 is buggy and not managing its business properly.

2. An aspect of windows itself or application function has changed and the interaction with that from TI 2018 (correctly) is exposing another issue in my system. TI 2016 may not be utilising the same procedures or mechanisms in windowns and not exposing the problem.

I think 1 is more likely than 2. 

My first point of interest is knowing if the Acronis cleanup removes EVERYTHING - all traces, including any common registry information it may rely on but leave just in case other programs need it.

Second point of interest is to do with the existing backups - what identifying info do they have that is presenting differently to a newly created backup?

Being mindful that the only way I have got my backups across network working is to add an existing backup to use (or before creating a new one to the same destination).

The above scenario works with 2 user accounts on my NAS - one of which I created specifically for this testing, the other being the older one Ive been using for ages with TI2016.

SAme scenario using a new Share.

To my mind this removes the focus from my accounts, policies etc and shifts my interest to TI - what is it accessing and where from. My hardware setup is not a usual home setup but it is NOT a fringe network topology. THis should be working.

I did some more specific testing.

I set the subnet mask to 255.255.224.0 just to remove that as a discussion point or source of problem.

1. Add old backup and reconfigure. Run backup task - works fine.

2. Reboot PC and NAS.

3. Run PC backup that then calls backup to NAS via script ->   Backup to NAS Fails. Same error as previously.

I simply cannot understand why it is working first time the old backup is found then failing after a reboot and re-running it from TI or calling the script from command line.

I think I have here identified the single use scenario where it actually works.... and have no idea why.

That's interesting!  I know that the Bonjour Service installed along with True Image is there to provide discovery of NAS devices without DNS.  According to the text file found in the service folder a users firewall may prevent discovery of an NAS.  Your experience would certainly qualify as not being discovered I would say. 

When you use your IP Address the application uses standard SMB Protocol to make connection.  I am thinking that using an IP Address may be an issue with the Scheduler perhaps.  Possibly making sure that Bonjour is not being blocked by your firewall might enable your NAS to be discovered and if so it would appear in the NAS folder of the TI app.

There is some information on this in a post from a Senior Acronis Engineer on the subject HERE

Below is a snippet of the Bonjour text file on Firewalls:

Firewall requirements

The Bonjour networking protocol sends and receives network packets on UDP port 5353. If you have a "personal firewall" enabled, you will need to ensure that UDP port 5353 is open for Bonjour to work correctly. Certain firewalls will only partially block Bonjour packets, so if you experience intermittent behavior, check the firewall settings and verify that Bonjour is listed as an exception and is allowed to receive incoming packets.
The Bonjour installer will configure the Windows firewall appropriately during installation on supported systems.

You might wish to investigate this and see what you can find.

Thanks I'll look this stuff over.

To frustrate me further my 10GBe card packed it in. Will not see any cable connected to it and registers permanent disconnection.   /sigh.

I don't think it is related to the issues I've been having as it was working in all other use cases prior to this morning. 

I have to announce todays testing as suspect though as I don't know precisely where it died :P.

Ohh well I'll see how good my warranty is! 

Telstra is screwing us around in my area at the moment - losing phone tower and cable coverage constantly. Posting here as I can.

All in all a frustrating day for electronic activity!

A few things from a quick search:

https://forum.acronis.com/forum/acronis-true-image-2017-forum/bonjour-and-immorality

https://kb.acronis.com/content/39490

https://kb.acronis.com/sites/default/files/content/2013/01/39490/wanbonjour_1.pdf

It may well be a problem around TI and how it's using bonjour. I do know that the LAN connected to my modem/gateway (which is the master browser) is seen under "NAS" .... and that is the function Bonjour is supposed to have.

My 10GB connection, not associated with any gateway or routing being a direct connection, does not show up on the "NAS" list. 

Acronis state in the above link about immoral use of bonjour that it is meant to function without it where an IP is described. Patently it is not doing that.

I guess if someone can set up a scenario to test my use case and let me know how it goes that would be super helpful. It would rule out something random I hope.

My firewall is controlled by BitDefender which is my AV program. I added the bonjour exe to it for assurance but it should not be blocked anyway, and a prev check with the firewall disabled didn't alter the outcome.

It will be interesting to read how things are after you replace the failed 10GBe card.  Any failing hardware component can introduce some very strange and unpredictable symptoms.

mgrobins backups:

My backup uses 2 scripts and the following setup:

1. NAS powers on 0200h daily

2. NAS wakes PC (WoL function)

3. Acronis scheduled to run daily backup on PC (local destination drive), then runs  batch to activate 2nd daily backup task. 

4. PC backup to NAS is performed. Credentials are an account on NAS that is only one with write privilege for destination. 

5. Acronis calls batch file to shut down NAS and PC once completed.

My personal experience is that ATI 2018 has issues when there are multiple backup tasks and there are pre/post commands in the task to a NAS.  So, here's the way I would recommend:

1. NAS powers on 0200h daily

2. NAS wakes PC (WoL function)

3. ATI scheduled to run backup to NAS at 0210h and backup to local drive at 0220h.  If the first backup has not completed, the second backup is queued and will not run until the first backup completes.  No need for a  batch (script) to initiate the second backup.

4. The first backup to NAS should not have pre or post commands.

5. The second backup (to local drive) should have the post command to shutdown the NAS and PC.

For sure!

I'll be annoyed if all of this was the card playing up but the consistency of the problem at the outset rules it out.

The part that *could* be relevant is if it started playing up around the point I was changing the subnets etc and re-testing. It may have stuffed up things and taken me (and you helpful folk) off track.

For now I've just pushed all traffic through the 1GBe connection and have the NAS showing 2 ports on the 192.168.1.x LAN. (at 2 and 3)

Interestingly, I had to manually enter the .3 port to get it to show up under the "NAS" tree in TI. I'm guessing that is the Bonjour Service in action.

My PC was hardlocked when I got up this morning and it was stuffed after that so I think it occurred then.

I'll chuck an old card in (sound card) just to ensure the PCIe slot is working and it is 100% the card. Interestingly the NIC still shows as working in windows but is listed as disconnected whatever I do. Nil lights on the card illuminated so it's a hardware fault I think (not windows / driver).

I'm tethered to my ph at the moment.... have to love reliable Internet companies :P

A bit of info for you.

I have found that the Bonjour Service for Windows uses mDNS or multicast DNS as a discovery method for local connected devices which is exactly what your NAS is as it is currently attached to your network.  It is possible to find out if in fact your NAS device is being discovered by the Bonjour service.  This can be done by using a zeroconfig browser which allows for viewing what Bonjour has discovered on a local network such as printers, NAS, other computers, basically any locally attached network devices.

I have found a small footprint zeroconfig browser which is freeware for private use only.  A link to the site where this browser is hosted can be found HERE

A direct link to the download .zip file can be found HERE

I have scanned the extracted .exe and found it clean but you are encouraged to use your own diligence.

I installed on one of my computers and it indeed found 2 printers my FREENAS server and a network attached external hard drive which is configured as an NAS which means, the Bonjour service is working as intended on my network.  I run a third party firewall which I have verified has the Bonjour Service listed as an allowed application in my Trusted non-public network.

Hope this may help.

THanks :). I'll check that out once my internet is working or I can get it downloaded.

I discovered an extra bit of the puzzle - and I do think it's a bonjour issue.

\With my 10GBe card out I connected my system as follows:

NAS : 

LAN port 1:  192.168.1.2, 255.255.224.0,  gateway 192.168.1.1 (router which is master browser), set as primary NIC on NAS

LAN port 2:  192.168.1.3, 255.255.224.0,   gateway 192.168.1.1

My backup to NAS via 192.168.1.3 failed again - destination not found , credentials .... same error.

THis time is starts backup sits at 109mb and stalls there as opposed to "checking timeframe" or whatever it does.

only 192.168.1.2 is appearing in TI under NAS and nothing under network.

NAS//192.168.1.3/   find the NAS and adds it under "NAS" but it doesn't persist after closing.  Also why is it // instead of \\ as in normal addressing? seems dumb :P

credentials check out ok. removal from registry and re-add them in TI.... still doesn't work.

Add existing backup in TI and reconfigure.... run backup - works immediately.

I don't think this is a network issue perse. I think this is a bonjour issue with TI.

TI2016 uses bonjour as well - so what have Acronis done in TI2018 that is causing it to fail?

As far as I can tell the TI 2016 version used Bonjour Print service version 2.0.2 whereas TI 2018 uses Bonjour Service 3.1.0.1 dated October 31 2016.  Different versions different behavior possibly.

If your OS on your PC is 32 bit (doubtful looking at your site) Bonjour will not work on Windows 8 or 10 32 bit versions.

Using the IP Address of your subnet connected NAS does not use the discovery methods of the multicast DNS of Bonjour Services.  Instead, it uses the IP of TCP/IP for discovery which then populates the device under the NAS folder.  Does the device showup under Network in the Destination window too?  If so what happens if you select the share on the device under Network rather than under NAS?

The syntax of network addresses uses the\\ instead of //, always has, always will.

Have you tried using the NAS device name rather than the IP Address to connect to it?  Example:\\Synology\MyBackup\

The Bonjour Service uses device names or DNS via the mDNS (Multicast DNS) zero-configuration networking (zeroconf).  The Bonjour Service simply announces discovered devices to a local network.  Using an IP Address circumvents that.

You have multiple Synology NAS devices.  If these devices have the same names that is more than likely your problem here.  Change the name of the device at 192.168.1.3 should get things working under your current configuration.  It may well fix the issue under your original configuration too.

ok a few things in there ....

1. the program you linked shows both network addresses on the NAS as being present with bonjour.

2. the 192.168.1.3 address does not show up under network or NAS unless I manually add it first. 

3. I have only one NAS in the equation here and if I use its name it will use the .2 address (the identified primary NIC in the NAS). As far as I am aware you can't have a different DNS descriptor for the same device??

4. Bonjour on my NAS does not have any AFP elements for printer etc enabled.... just the basic bonjour setup. Equally the SMB setup is just SMB2 and SMB3 with none of the extra options altered.

5. I'm aware bonjour uses DNS which is why I cant understand the interference with specified IP links. 

6. I still cannot understand how the above factors translate to a working backup only once if its added from an existing backup only ....

Ok, I was under the belief that you had two NAS devices because you used the word multiple in your system description. 

What model of NAS do you have?  

Using your current configuration of 2 gigabit connections on the same subnet to my knowledge will not work as 2 independent networks.  

alrighty...

THanks Ftr for the info regarding queing... I can eliminate one aspect of things by just using 2 scheduled backup tasks :). THanks 

I've not had issues with pre/post commands though myself.

I have my 10GBe LAN running again. X550-T1 in place in my PC.

Reinstalled NIC drivers, reconfirmed settings, disabled Bitdefender AV.

Networks set to Private and am using windows user accounts not homegroup.

Enabled the SMB1 server in windows (previously was off by default following the Creator update). THis allows me to 'see' some of my other devices like media server on my nas in windows explorer.

In my NAS (Synology DS 3617xs) I enabled the printer and file sharing elements under bonjour service.

LAN 1GBe: 

PC 192.168.1.6, NAS 192.168.1.2, gateway 192.168.1.1.  Subnet 255.255.224.0,  unmanaged switch.

LAN 10GBe:

PC 192.168.0.7,  NAS 192.168.0.3, no gateway, Subnet 255.255.224.0 

SMB file copy from NAS to PC is just fine. Physical link is working and passes diagnostics.

TI 2018:

Network: PC, 192.168.1.2 (1GBe NAS) name resolved, and laptop

NAS: 192.168.1.2 (1GBe) name resolved

192.168.0.3 (10GBe) only shows in NAS after I browse to nas:\\192.168.0.3\

Added existing backup. credentials accepted. Backup runs ok.

Reboot NAS and PC

Run same backup task to NAS - initiates, sits at 109mb "calculating timeframe" and produces the same error I have had since the beginning.

I'm confident if I reinstalled TI 2016 it would "just work" again as it has since I bought it ages  ago.

As far as user level adjustments to make this function as it should.... I'm stumped.

Acronis Support have my system reports. I'll attempt (again) to upload other infor they want to their FTP site to get them involved as well.

mgrobins, I agree with you that ATI 2016 would not have this problem.

I backup my computer twice a day to my Synology NAS, using 2 separate tasks.  Each task uses a different NAS login.  Each NAS login only has access to one shared folder, and write permission are limited. ATI can create files, but cannot edit or delete them.  Therefore, I do all cleanup activity using the web login.  I have not had any issues with this setup until I added pre/post commands.

Several months ago, I developed an app to automatically delete log files that are older than 3 days old.  I added the app as a post command.  The next day, the backup (task) failed.

Here's the error message I get in the ti_demon log file:

"4/2/2018 9:55:15:237 AM   Error 0x1e50023: Cannot access backup file \\SPANGLENAS\Asus_Num2\Mo_Mar18\AsusROG_318a_inc_b1_s17_v1.tib. Please ensure that you entered the correct credentials for the network share.
4/2/2018 9:55:15:253 AM   Error 0x101f6: Write error"

Originally, I thought there was something in my app causing the problem, so I stopped using it.  I recreated the backup tasks without the pre/post command and they ran with no problems.

Then Patrick O'Keefe had a similar issue.

https://forum.acronis.com/forum/acronis-true-image-2018-forum/how-safel…

So, I added pre/post commands back in and the tasks started to fail again.  I am convinced that pre/post  commands are part of your problem.

Is there any way you can create a new task to your NAS without pre/post commands?

You could use my recommended steps above or your could run the NAS task second without pre/post commands and have the task shut down your computer:

Then your NAS would eventually go to sleep due to inactivity.

I plan to try to duplicate your problem, but I cannot do that until next week.  I am heading to Augusta GA for a golf tournament.

Regards,

FtrPilot

Cheers and enjoy the golf :).

Last time I played was before I got out of the Service; back is too smashed up now to play and I need to be super careful of my hands for work!

I will test without the pre/post commands to rule that out.

It sounds like you have a very similar setup to me in regard to use of accounts and limiting access. My "acronis" user account only has access to the backup share. No other account has write access and my other accounts are read only for all shares bar one I use for a repository. I do all of my file management from the web interface.

I initially set this up to prevent a cryptolocker hitting my backups. Some of you were a party to a thread/discussion I had around this structure a year or so ago (TI2014 related).

THe post command on my local backup does not seem to be breaking the local backup.

I do use a post command on the backup to NAS to shutdown the PC and NAS once backups are complete.

I like the usability of TI in general, but if it keeps growing and having issues for my fairly limited needs I may need to look elsewhere after TI 2016 reaches end of its life. I want something streamlined that doesn't run 6+ processes in the background and load down my system.

Yes, we have very similar NAS setups.  Another thing I have done is create an "Admin" account using a different name, then disable the real "Admin" account.  All other accounts have limited privileges.

Question:  When the backup fails to run, do you always get the v11 error?  Or do you get a credentials error like I show above?  I always get the credentials error and have been unable to generate the v11 error.

Like you, I only get a failed backup when the pre/post command is in a task that backs up to the NAS.  No problems if the pre/post command is in a back up to a local drive.

I am very interested to see if removing the post command from your task fixes the problem.

On another subject...thank you for your service.  I did 20 years in the USAF...retired in 1992.  Later this week, I will be at the Masters with 40,000 of my closest friends.

Regards,

FtrPilot

mgrobins,

Question for you.

Do you have the Ethernet ports on your NAS setup as aggregated links or failover?  

Your device user guide discusses these features.  It goes not discuss independent networks which is not supported on the device. 

Aggregation combines available connections in parallel to increase bandwidth over a single network.  Therefore, the Primary connection will be what TI uses for connection purposes.  If you select the IP address of a none primary connection as destination you might fool the app into using the link on a run once basis but would fail after that.

Randy might be onto another issue here totally separate from this one and may in fact impact you.  Will be interesting to see if the post command issue is at work here too.

mgrobins...I have one additional suggestion.  Background...ATI stores information about the existing backups in a database file.  The information in the database file could be contributing to your problem.

In this process, have you performed an un-install then re-install?

My recommendation is to perform an un-install then re-install.  Then add the existing backup that's on the NAS.  Reconfigure the backup and do not add pre/post command.  Then, with that as the only task scheduled, see if it succeeds using my recommended process (NAS wakes up at 0200, NAS wakes up the PC, Backup Task runs at 0215, Backup Task is set to shut down the PC at completion).  Once you are satisfied that this task is running properly, then add the backup task to the local drive.

Next week, I plan to set up my test as I have just described.

Thanks for continuing to assist me with this :). 

I have performed uninstall and reinstall with no change.

I do not get the .v11 error .... only the credential error.

My NAS setup has no failover or other aggregation/teaming activated. Simply independent connections with precedence given to one.

I would expect independent networks to not require mention.... would that simply be implied for any Linux based device?

I will invest a little more time today checking the pre/post command suggestions and generating the logs and reports the support ticket requests for submission.

Ftrpilot - thank you also for your Service. In Australia that's something I very rarely hear.... perhaps twice in 4 years. For all it's apparent inconsistencies the US does seem to have a deep respect for its military personnel and what they give. 

If I can find the Master's on TV I'll keep an eye out for someone with a flashy gold watch, baseball cap and a set of aviator's :P ... 

mgrobins,

Your problem with your network configuration is that you have 2 nics in the same computer using the same subnet.  This is a no no in configuration.  This will cause conflicts in your network and is doing so in this instance.

You need to place one of your nics on another Private subnet if you want to use them as independent connections.  Your subnet mask in such an instance would be 255.255.0.0 for both nics but your IP addresses would be say 192.168.1.2 subnet 255.255.0.0 for your NAS LAN 1GBe.  Your IP address would be say 10.0.x.x subnet 255.255.0.0 for your NAS LAN 10GBe connection.  This will give you 2 independent local network connections whereas what you have now does not.

For in depth details on this look HERE

ok cheers.

I'm using 2 separate subnets again. at any rate (as I did initially). 

It's been years since I had to formally design network topology.... 255.255.0.0 should ensure the NIC accepts traffic on the same net of ...192.168.x.x correct? Whereas before it was only considering the last address value...

I had considered that the 2 networks were separate physically and not looked at services like bonjour that might not play well with it.

I'll let you know what I find! 

Yes, it should work.  The best way to do this is with routers.  Connect one router to another and bridge the 2 connections.  You can bridge the NIC's in Windows as well.  If however you want to keep your NAS from gateway access bridging is a no no.

I think the problem you have here is that Windows and TI are going back to a default of the Primary network connection thus limiting your ability to setup a scheduled backup to your secondary subnet.  That I suspect is by design and expected behavior.  So unless you are willing to get the 2 subnets talking to each other you will face this limitation.

Have you tried pinging from one subnet to the other?  That would tell you if they can talk to each other.

I think you are over-complicating what is required.

Building a 10GBe router would be serious overkill for my circumstances.

Windows 10 using SMB3 has very well developed capacity for managing multiple NICs dynamically. That's likely what enabled me to use my setup with zero issues initially as you are correct both LANs were on the same subnet due to the subnet mask of 255.255.255.0 and IP ranges 192.168.1.x and 192.168.0.x.  A mask of 255.255.0.0 with that setup would have worked as well as your suggestion for using 2 entirely different IP ranges with 10.0.x.x in the private range.

Interestingly this had been working perfectly for all use cases I threw at it (including TI 2016), and only has issues with TI 2018. No other software is problematic. The bonjour service checker you suggested shows each device recognised as well.

I am not using multiple IPs off a single MAC address therefore each LAN is structurally separate. Adding an additional router and trying to bridge an interface to route traffic is not needed as traffic should be managed at the device level. 

I have now adjusted my subnet masks and for simplicity am running 2 entirely different IP ranges for local use.

1GBe: 192.168.1.x  /  255.255.0.0  gateway: 192.168.1.1

10GBe: 10.0.0.x    /  255.255.0.0    no gateway.