Rescue Media is refusing to let me access my NAS

Bruno, I haven't attempted yo connect to my NAS with the rescue media lately but will try tonight to see if I can or not.

In the meantime, can you use the command prompt with net use to successfully authenticate and assign a drive letter directly in winpe rescue media? If so, then Acronis should be able to at least pick that up once the drive letter has been assigned.

https://www.google.com/amp/s/www.howtogeek.com/118452/how-to-map-network-drives-from-the-command-prompt-in-windows/amp/

Thanks Bobbo, using the net command worked for me. It did feel like it ran slower though, so I'm not sure what's going on there. Also, I noticed that the size of the C: backup was 87GB, whereas a C: backup run through the Windows UI last night was 105GB. Both excluded pagefile.sys, swapfile.sys and Recycle bin. The Windows version also excluded other things so why would the rescue media version be so much smaller?

Size difference could be explained by different levels of compression being selected.

Ian

Compression and any difference in exclusions. When Windows is booted, it creates other temp files in system32 and appdata. You could mount the .tibs as volume letters in Windows and run treesize against them to see where the major size difference comes from if it is something actually in the backup and not just compression.

Edit... Maybe the OS backup also included system volume information folder? That's where the temp files for VSS snapshots are cached first. I think those are a default exclusion in the OS backups though.

Not sure about speed difference. Net use is the back end for mapping network drives so should be similar performance. My guess is possibly drivers for the network adapter in the rescue media than the regular OS? Or maybe just felt slower but really wasn't that different? The log would tell you the start and end time and then could compare it next time.

Bruno, just curious but are you using a fast ring or beta insider version of Windows 10 either? Just checking because Mustang previously found that several of the insider versions had incomplete WinRE environments that either left components of the basic recovery (without even getting into the Acronis parts) broken or completely missing. So if we can at least rule that out, I'll create winpe and WinRE later tonight and test them both out to see how the authentication to my NAS backup share goes in both.

Maybe the compression explains the size difference. I don't think it's the exclusions. On the other hand, when I mounted the .tib, I saw stuff that I thought should have been excluded so not sure what that means.

I'm using Windows 10 Version 1803 Build 590. I created the Rescue drive under Build 523. I don't run insider versions.

I just ran the same backup to a USB thumb drive and it took twice as long as my NAS backup. I know that different thumb drives can have quite different performance characteristics so I don't think much about that.

And one more thing about the use of the NET command. Although it worked to access the drive for the backup, when I tried to save the log after the backup completed, my mapped drive did not appear in the list so I had to save it elsewhere and later copy it over.

Odd on the drive mapping dropping. It's a straight Microsoft command. You can run net use and see what's still "supposed" to be mapped too as it should stay mounted unless specifically disconnected.

Also, you can use A43.exe which is in x:\program files\Acronis\TrueImage\A43\a43.exe

To help see what's mounted and it has an option to mount network shares directly through it's own GUI too.

I will try to test the basic mapping in the rescue media with winre and winpe tonight though!

Bruno, I posted my results over in this thread:

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

I really didn't have an issue connecting to my NAS using WinRE or WinPE.  I did note a couple of anomolies once the drives were mapped, but nothing major now that I know the behavior.  Basically, I'd actually recommend using net use with /Persistent to keep the drive mapped or A43.exe as it is doing exactly the same thing.  

I think when Acronis GUI connects to the share it is using the IPC (which I'm just learning about) and that may prevent the share from being connected again if you use net use to disconnect it and try to remap it manually.

https://support.microsoft.com/sr-latn-me/help/3034016/ipc-share-and-null-session-behavior-in-windows

When I have some time I'll try again and look into A43.exe.

Meanwhile, as I mentioned in the original post, the problem is that the authentication is failing for the NAS when I enter the NAS name in the True Image UI. But through the NET command, authentication works just fine. Would there be anything I should reconsider in how I build the rescue media?

Yeah, that one I can't explain.  I just did 3 more tests and updated in the other thread.  All authenticated just fine for me to my NAS using Linux recovery, WinPE recover and WinRE recovery when using the Acronis GUI.  

Make sure you're not using the # pad, but instead the default number keys.  I wonder if there could be any keyboard mapping issues as well (like if using UK English instead of US English) where the keyboard layout may be different and resulting in a bad password?  You can use A43 or command prompt to just type and see what is being presented when you enter your password in them to make sure what you would normally be entering into Acronis is what is really expected.  Maybe numlock or a different keyboard layout is really the issue here - I don't know, just a guess.

Also, I found that after the backup, when using net use, the drive does disconnect when completed.  net use still shows it mapped, but if you try to find it in A43 or switch to it in command prompt, it says it's not found.  I would have to delete the share with net use /delete * and then map it again - seems to be a WinPE thing and not an Acronis thing.  

But since I didn't have issues connecting to NAS shares in Acronis with any of the 3 media options, I'm not sure what else could be the issue in your case (other than the key mappings possibly being different)

First thing I did was make sure it was not a keyboard mapping issue. All is OK there.

If I use the NET command, when I specify the NAS as a drive letter I get an Authentication Settings menu command. Pressing that opens up the box with NT Authentication option checked. I test and it works just fine.

Now, an question from ignorance: how can I place a simple batch file to automatically do the NET command when I boot off the rescue media?

OK, further tests...

On my NAS box, I have a folder called Acronis where my backups go. When I used the NET command, the format was
net use z: \\NASbox\Acronis /user:<userName> <password>

When the Acronis UI was trying to authenticate, it was always trying just with \\NASbox\.

So, I ran this net command:
net use z: \\NASbox\  /user:<userName> <password>
and it failed.

Watcha think?

If it's an .iso, no can do.

If it's a USB drive, just place script.bat (call it what you want) somewhere that's easy to access with command prompt and launch it.

Alternatively, build the rescue media with the MVP tool.  Then do the same thing, but it will be easier to get to it with A43 or file explorer++. 

EDIT*** There's also a folder called "extra" in the custom pe builder portion of the tool.  If you put any other files/folders in there (MVP_ATIPEBuilder_v186_Signed\Extra\x64), for instance, say portable apps or scripts like this when you build it, they'll be added into your custom PE there.  Then there is a start menu button in the PE that will take you right to that Extra Users folder in Explorer++ which makes it easy to launch, just by clicking on the .bat file script.

Further to my last post on the net command... same result running under full Windows 10.

I missed your last post - showed up after mine.  Yeah, it's likely that the root of your NAS doesn't have the same permissions as the Acronis folder.  Are you able to share that as well?  If not, when I used the Acronis GUI, I manually typed in the full path of the share and then authenticated. Forget about trying to access it from the menu or dropdowns... instead, when it asks you to locate your backup for recovery or where you want to create the backup, just go into the path and type it in manually.  And use the IP instead of the DNS name so you don't have to worry about any name resolution either.

One reason you might not be able to get to the root of the NAS - is it's not shared out.  Or, it is shared, but only to say an admin or different account than you're using for your Acronis backup.  

For clarification, I just tested this and I too get prompted for credentials as soon as enter \\192.168.1.100.  I cancel that, and then finish typing the rest of the path and am prompted for credentials again.  At that point it connects then.  I'm able to connect at both points, but in your case, try canceling the first time to see if you can keep going and connect then.

It isn't working the same way for me. When I enter the NAS as either \\NASbox\ or \\192.168.1.108\, as soon as I enter the backslash at the end I get the dialog asking for credentials. I can easily escape out of that but as soon as I enter the next character the credential box comes up again and is still trying to get credentials for the root. So I cannot get past that.

Under Windows, I can open up an Explorer window and just type the \\NASbox or \\192.168.1.108 and I see the folders on my NAS, just as I want. I've tried to find some way to configure the users for root access on the NAS but I'm not finding anything.

But on the other hand Windows Explorer handles it right. And the Windows ATI user interface works fine as well. When I create a new backup and enter \\NASbox in the destination, it will find it and put it into the tree under Network.

I'll try to get 2018 installed on a VM and see if I can duplicate or not. I will be building with ADK 1809 though. If my test goes ok, then maybe you'll want to upgrade your ADK and try that. I'll report back later tonight but need to step away for a bit.

I've been playing with this and found it works quite well. Here are the steps I used to connect to a network share using the Acronis GUI:

1. Select recovery.

2. Leave the box with a path empty and click the Browse button next to the empty box.

3. Click the arrow next to Network in the left pane and wait a few seconds. Entire Network shows up under Network.

4. Click the arrow next to Entire Network and wait a few seconds. A folder shows up in the right pane that says System folder next to it.

5. Single click the folder icon in the right pane. This causes two backslashes to appear in the File Name box below.

6. Type the Computer Name or IP address of the machine with the network share you are trying to reach after the two backslashes.

7. Type only a \ after the name or IP address. This causes an authentication box to show up. Sometimes two authentication boxes show up (one on top of the other). The box on top will probably fail to connect. If it does, close the error box and put the username and password in the second box. This should connect.

8. Wait a few seconds and all the shared folders in the root of the machine show up in a drop down box.

9. Select the share you want and it will show up the in the right pane above.

10. Click the shared folder in the right pane and all the subfolders in it will show up.

11. Double click a subfolder to drill down to the folder with the tib file and the tib file will show up.

12. Click on the tib file and it will be added to the path in the file name box.

13. Click Next and the recovery will continue.

Bruno, if you drill down and can't get to your Acronis folder, it means the permissions are not set properly to share that folder (as Enchantech has already mentioned).

Rob, there's no need to delete any share. I am able to close the TI GUI and then re-open it and repeat the above steps. The only difference is that I don't need to enter any credentials the second time. I even played with deleting the ICP$ share after the first connection. After I closed the TI GUI, I opened a command prompt and entered "net use". It showed the IPC$ share. I entered net use "\\ComputerName\IPC$ /delete" and it deleted. I went back to the TI GUI and browsed to the share again using the steps above. 

Mustang could you send me the 2018 installer?  Silly me, the one I didn't keep a version of and the subscription only lets me grab 2019 now with no option for a previous version!  Just need the latest installer so I have it handy down the road and will license it with my subscription logon.  Thanks!

Mustang wrote:

I've been playing with this and found it works quite well. Here are the steps I used to connect to a network share using the Acronis GUI:

1. Select recovery.

2. Leave the box with a path empty and click the Browse button next to the empty box.

3. Click the arrow next to Network in the left pane and wait a few seconds. Entire Network shows up under Network.

4. Click the arrow next to Entire Network and wait a few seconds. A folder shows up in the right pane that says System folder next to it.

5. Single click the folder icon in the right pane. This causes two backslashes to appear in the File Name box below.

6. Type the Computer Name or IP address of the machine with the network share you are trying to reach after the two backslashes.

7. Type only a \ after the name or IP address. This causes an authentication box to show up. Sometimes two authentication boxes show up (one on top of the other). The box on top will probably fail to connect. If it does, close the error box and put the username and password in the second box. This should connect.

8. Wait a few seconds and all the shared folders in the root of the machine show up in a drop down box.

9. Select the share you want and it will show up the in the right pane above.

10. Click the shared folder in the right pane and all the subfolders in it will show up.

11. Double click a subfolder to drill down to the folder with the tib file and the tib file will show up.

12. Click on the tib file and it will be added to the path in the file name box.

13. Click Next and the recovery will continue.

Bruno, if you drill down and can't get to your Acronis folder, it means the permissions are not set properly to share that folder (as Enchantech has already mentioned).

Rob, there's no need to delete any share. I am able to close the TI GUI and then re-open it and repeat the above steps. The only difference is that I don't need to enter any credentials the second time. I even played with deleting the ICP$ share after the first connection. After I closed the TI GUI, I opened a command prompt and entered "net use". It showed the IPC$ share. I entered net use "\\ComputerName\IPC$ /delete" and it deleted. I went back to the TI GUI and browsed to the share again using the steps above. 

I agree with all of this with 2019.  Having no issues connecting to my NAS at all in any of the 3 rescue media for 2019, but just want to double check with 2018 to be sure there isn't any difference with the latest version.

I guess the big question though, is why Bruno can access the share just fine from Windows and also just fine with net use to mount a drive letter in WinPE, but getting access denied in the WinPE Acronis GUI - perhaps there is a second credential window behind another causing this behavior in his case as you saw in your testing Mustang.  I haven't seen that behavior in my own yet.

The issue that threw me off yesterday was when I mapped the volume with net use and ran the backup.  Either Acronis or WinPE disconnects the share when it's done, but net use will still show it's connected.  However, if you try to connect to it from command prompt or A43, it says it's not there.  So, I'd have to delete it with net use and re-add it again if I wanted to do more than one backup at a time testing.  Bruno had the same behavior in this regard too. 

From a clean boot to the rescue media, I tried the Mustang steps, but still did not help. Same issue as with the Backup route.

But, I did use the NET command to make the NAS accessible, ran a backup, and then the drive letter for the NAS was no longer available. I then tried Mustang's steps and it worked, providing me access.

I believe that once the NET command gets through Windows credential verification, then it works. I wish there was a way to set up Windows credentials for the NAS on the rescue media in a persistent way.

Bruno, you can mount the boot.wim with DISM and modify the startup script to run it before Acronis launches.

Easiest thing is to build the rescue media with the MVP tool which provides the option to automatically boot your share with a drive letter with the credentials you provide.

Or, write your script and add it with the MVP tool and put it in the extra file folder so your can call on it easily in file explorer++.

I had trouble getting the 2018 media but have it now and hope to test it compared to my 2019 media tonight.

There is a way to add the net command to the media. We have made it very easy with the MVP Tool. During the build process, you will see a question to automatically map a network share. Follow the instructions and you are done.

Just for a comparison, I created a Linux version of the rescue media. It works! When I enter in \\NASbox\ and the credential window pops up, I enter the username and password and it connects perfectly. I can then see the folders on my NAS drive.

That discounts the NAS box itself as the problem so I can only assume it to be a bug in the WinRE version. Whether it is in the Windows system or the ATI program I cannot say.

Usually, I run my backups to the NAS on schedules with ATI under Windows. When I use Rescue media, I'm usually doing periodic offsite backups to a USB drive. So this was the first time in quite a while I had approached using the Rescue media to backup to the NAS. Can't say if it worked before, or when that might have been.

Bruno, I created rescue media with the current version of Acronis 2018 and WinPE 1809.  I had no issues connecting to my NAS.

I will say, WinPE network shares are a bit "interesting" after more testing today.

In my case, if I open Acronis first and click on "backup" and start typing in my path as \\192.168.1.100 when prompted to authenticate, it takes the username and password just fine.

When I check "net use" this shows that \\192.168.1.100\IPC$ is connected.  As Windows as a limitation of only allowing one user session to a remote share at a time, this is now the dedicated required connection.

But, if I delete this with net use (which I can), then in can use net use to map it as a drive letter and delete it and map it again (over and over).

UNTIL... I open Acronis and attempt to use the console to connect to the share the regular way again.  I then end up not only with 

\\192.168.1.100\IPC$, but also \\RBD-My-Cloud.tmobile.com\IPC$ and this is where I run into authentication issues in True Image like you see.  I don't think it likes having two IPC$ at the same time and don't know why it allows or ends up with both.

Once this happens, I can manually use net use to delete both, but then I can't map to my Acronis NAS with net use either!  I found that I could map to a different share (using same credentials) and that would work.  Then, I could delete that and then I could map my Acronis share with net use again!

But, after this, it is nearly impossible for me to enter the credentials in Acronis again.  I saw the network helper or whatever you saw before after this which fails to connect (in a command prompt like window) while the Acronis credential window popped up.  And when I checked net use again, I had both IPC$ showing, but had never provided the correct credentials.

Long story short.  For me, it works just fine if I stick strictly with the Acronis GUI and manually enter my credentials, but I am able to do this from the root share of the NAS and my Acronis backup share (or either one).  IN your case, it looks like the root has an issue connecting and may be resulting in two IPC$ connections or something along those lines.

So, if using WinPE rescue media, in your case, I'd recommend just mapping the drive with a letter first and then using the "my computer" setting in Acronis to connect to the drive letter and not attempting to authenticate through the mynas or my network options.  

This does appear to be Windows PE/RE behavior at work, and not Acronis (well not intentionally, just because of limitations of the NAS communication initially with your particular NAS). If Linux rescue media is working better for you, no harm in using it.  I personally don't use (and really can't use) the Linux media since it doesn't have drivers for my PCIe NVME drives and like being able to add my own drivers in the WinPE and the customizations of the MVP media.  If it's easier to use the Linux media in your case, do it though!  

I've learned a lot about the WinPE media shares today.  I have a 30minute video I will post later - yeah it is probably boring, but it will show how the behavior in the WinPE changes after trying different connection methods in the same WinPE session.  I need to edit and clean it up though as there are a few instances where my password is shown.  

Thanks, Bobbo. I'll look forward to being bored by the video.

I do recall that I had tended to use the Linux version before so that may be why I never experienced this issue before. I also have and NVMe drive (960 EVO) and no driver issues. It works fine under Linux.

And I'm not sure if I mentioned this before but my NAS is a Synology DS213j.

One more question. Under the WinRE, the open command window does not have a prompt after the line to open ATI. So to enter a command I first need to exit ATI. Then I get a prompt. But when I then restart ATI, a prompt will appear right away so I can go back and forth. Is this normal?

Yeah, if the NVME is in AHCI mode, linux works. A lot of manufacturers are setting the bios in RAID mode with these drives though because the queue depth of AHCI is really small compared to RAID. Basically to get some extra performance out of the drives, but probably not noticeable in most real world stuff.  But when it is in RAID mode, you need the IRST drivers in winpe as they're not available in the Linux recovery media still.

Yes, that's the same behavior for me too with the default winpe / WinRE rescue media. Have to shutdown ATI to get to command prompt and then can launch the commands or A43 and launch Acronis again.

Have you tried the MVP builder? It makes the Winpe feel a lot like a real OS with a GUI environment where you can do a lot more easily. 

I believe Ian and Steve both have Synology NAS too, but not sure what version or firmware. Maybe they'll chime in on how the rescue media is working for them to access. I know Steve has said he's pretty much only using the MVP custom winpe these days.

OK, I whittled it down a little with some quick and rough editing.  Basically, just wanted to show that WinPE has a few ways it's trying to connect to NAS shares.  Apparently, it can get "confused" or perhaps prevented from connecting under certain circumstances.  The most reliable way I found was to specifically map a volume letter and connect to that.  As you found though Bruno, once the job is done, the volume letter seems to just go away.  The way around that seems to be to delete the share (which still exists when you run "net use" and attach it again.  I did more testing trying to use the other "network" and "mynas" options in the Acronis menu, but no luck there.  This really just seems like WinPE being a bit flaky in this regard.  So, if it has trouble connecting to the NAS share right off the bat, it may cause some issues connecting on subsequent connections.  If that happens...

1) use net use and delete existing IPC$ share

2) use net use and assign drive letter volume to share

3) go into Acronis and connect to the drive letter as if it were a local drive volume and backup or restore

4) afterwards, it's likely to disconnect the volume automatically, but may still show up in net use or A43.  If so, delete the drive letter in net use and map it again if you want to save the log file on the NAS or validate or something else.

The video is uploading now. I'll edit and attach here as soon as it's ready.

OK, I made an MVP WinPE boot drive... and it is still problematic.

Bobbo, in your video I see that once you enter \\192.168.1.100\, you get a drop down and you can see the folders. In my case I immediately get to the authentication box. So it is asking for credentials for the root, not the folder. Look at the picture I took. Not only do I get the authentication box, but I also get a command window from CredentialUIBroker.exe. Neither of these will accept my credential. On your video, it seems to always be asking for authentication on the folder, not solely the root of the NAS.

One small difference between the WinRE and MVP WinPE version is that on the WinPE version, I was able to keep entering letters to get the folder identified. Problem is, it asks for authentication after each letter and I cancel it out. But once I got to a folder name and a backslash after that, then the authentication box showed the folder after the NAS name and I could then authenticate. This didn't work on the WinRE version.

I give up. Time for a bourbon. If I need to back up from the rescue media to the NAS, I'll either use the Linux version or the net command. Aarrgh!

Hi Bobbo,

I watched most of your video and made a few observations.  First, I note that your RDB_NASbox I think you call it is nested directly after the IP Address.  This tells me that you are not under authentication of a user.  So when you are entering credentials they must be for root.  I do not know what Linux variant the MyCloud uses but doing what you are as root in Linux is a very bad idea.  Anytime you logon as root unless you are a Super user or doing so over a secure connection then you are punching a security hole in your NAS meaning anyone whom can logon to your network has the potential to gain access.

You should be only making connection as \\IPAdress\MyCloud\share followed by user: credential when user: is owner of the share.

I am going out for the evening and will check back to see if you have responded when I return later tonight.

Hey Enchantech, just got back from the brewery :)

That account is not Root.  There is a root account that is only accessible via SSH through terminal and that one is only used for accessing the back-end of the NAS through putty.  And, I have SSH disabled usually too.

I double checked the permissions and cannot even log onto the NAS with the account and it is only allowed to access the shares that I have granted access.  It does have full access on those shares though so it can read and write, but the accessible shares are specifically selected on the account.

I have no idea why it can reach the root as is since that isn't a specified share.  However, being this is a 4 year old WD-MyCloud-4TB (original version), the security and firmware updates aren't very often, but it is as current as available: 

Available Updates

New Firmware Check for Update 

Current Version WDMyCloud v04.05.00-327 : Core F/W

Last Update Wednesday, May 30, 2018 6:58:57 PM

It's about as "consumer" as you can get and probably not the most secure, but I have it as locked down as I can make it with the settings available.  All remote access and media sharing is disabled.  The main account is the only one that can log onto the NAS through the browser console, but is denied access to all shares.  The account I use to access the shares is not allowed to access the web console.  Root is enabled, but only accessible via SSH, which is disabled currently.

I guess, each NAS is a little different based on what's running under the hood and will respond a little differently.

BrunoC,

Cheers to you bourbon buddy!  Whatcha having?  I just polished off my fist bottle of Jim Beam Distiller's Cut last night.  Don't knock it cause it's Jim Beam - it was excellent and a one-hitter so I grabbed 2 more bottles since it's out of production.

Now, what to have tonight?

Bobbo, I'll be right over!

I usually just drink VO or Bulleit. My cabinet does not look like yours (wish it did).

Bulleit is good stuff! My Raleys has the 10yr for $31 almost regularly if I wanna splurge but the original can't be beat when it's available for $20. I've been trying all the bottom shelf ones lately and finding some really good ones for $15-$20ish. I passed up fighting cock so many times, but actually like it as much as WT101, maybe even more and it's exactly $15. Great price for a strong, but drinkable sipper.

Bobbo,

Not sure about that MyCloud device.  Given what you say I must think that when you create a user, credentials are set then, you create shares and they belong to the user.

In my case with the FreeNAS server I only connect via the Web browser console as root via TLS /SSH as a Super User for system management purposes.  For general access I access as an authenticated user.  I do not use IP address at all as I have the ability to use Zero Config discovery so my FreeNAS shows up in WinPE in the view tree under NAS as Freenas and is easily navigated.  When I do so True Image gives me a Credentials logon box that looks identical to that of the Windows installed app.  

Having said that I had not done a WinPE backup in some time so decided I would give i  a go.  I navigated to my desired folder and was presented with the Credentials box along the way which I entered my credentials and connected without issue.  What I found was that like you demonstrated in your video I had to add a filename for the backup in the path statement to get the backup to run.  If I left out the filename then I got a command prompt credentials prompt which would not do anything.  I simply closed it, added a filename for the backup, and the back task continued to the confirmation page.

After the above I figured I would try the same backup to my TerraMaster NAS.  It works a bit differently as it does not use a web browser for access.  Instead it has an installed application that you use to log on as root for system management.  You then create an authenticated user account, then shares for that user.  You can also map a drive letter to a share in the app if you like.  This device uses NetBIOS as a discovery method which is most common and therefore it is necessary to use the IP Address for access.  I did so in the True Image app and navigated to the share folder.  I was prompted for credentials along the way which I supplied and easily connected with.  I ended my path with a filename and the backup ran fine.  I did not get the command prompt credentials prompt because I gave a complete path with filename to True Image. 

After doing the above I think it is the True Image app that has issue.  I think the app should allow you to enter path to the share and the destination folder without the filename and at that point you should be able to click on the Next button where you would be taken to the next step in the backup task process, ie. adding a filename.  Instead of that happening what you get is the command prompt credentials prompt.  That seems to me to be wrong.

I used the latest MVP WinPE build to perform the above.  No drive letter mapping was used only share names and either hostname or IP Address as required by device.

I think your experiment with drive letter assignment is interesting but totally unnecessary for this purpose.  Using drive letter assignment adds many more steps to the process than is required to make connection to a network share and run a backup task.

Oh and by the way, once I was logged on to my devices I was never prompted for credentials again and I navigated back and forth just to see if I would be prompted but never was.  This means that connection once established to a device share remained for the entire session. 

Enchantech, I'd say the drive letter mapping is unnecessary in most cases too.  However, seeing as Bruno is unable to get to his NAS with the WinPE through Acronis directly, we were hoping to find a solution or alternative - and in his case, mapping volume letters in WinPE seems to be the way to go, or use the Linux media for now. 

He doesn't have this issue in the Linux media, just the WinPE.  And he was able to connect to the share in WinPE using net use to mount the volume letter, but not directly through Acronis as it can't connect to the share due to "failed credentials" that never seems to work.  

Could be security on the NAS, but odd that it works fine in Windows and the Linux recovery, but not the WinPE recovery.

Seems like there are other issues at play for sure.  I tested again this morning to my Windows 10x64 Pro share and it worked in the Acronis GUI just fine.  In that instance, like you, I could authenticate the very first time and from then on, Acronis GUI in WinPE could connect to it just fine without ever having to enter credentials again.

So, best I can say is, mileage will very based upon different NAS devices, what settings and security are configured on them, and what settings and security they offer under the hood.   

Anyway, I think I'm done with troubleshooting this one, but glad to have learned a little bit in the process as I'm sure others will eventually have similar behavior as BrunoC when using WinPE rescue media too.  When it works, it works.  When it doesn't, well, maybe net use will come in handy for some.

Bobbo,

Agree that tools such as the net commands are useful and have purpose.  I am interested in discovery of the underlying problem that Bruno and others have.  I notice in Bruno's post above that he references CredentialUIBroker.exe.  It is the same command prompt authentication window that I spoke of.  There is absolutely no reason for that to show up in my view.  Same goes for the continued popup of the True Image Credential box at each keystroke, not necessary.

What should be happening is the user should type in the path in the browse field to the network share, if the share has a drive letter assignment then include that in the path statement.  Once the share folder is input then when the user clicks on the Next button in the True Image app should then trigger the True Image Credentials box for username password input and authentication and once that is complete then the app should move on to the next step in the process for backup which is give the backup a name.

So I  think this issue is a bug in the Recovery Media application and I applaud Bruno for bringing to light here in the Forum, you for your efforts to come up with a workaround, and everyone else whom has offered testing or advice.

Hopefully this will come to the attention of Acronis and it can be fixed.

Enchantech,

I don't think there is a bug here. Apparently, IPC$ can't connect directly with shares. Instead it connects to a machine. After the connection to the machine is established, all the shares on that machine become available. The shares become available using UNC paths not drive letters.

The attached screenshot was taken in WinPE before True Image was used. I used "net use" to make the IPC$ connection to a machine called Win10-64Bit. Then I used "net view" to list the shares on Win10-64Bit. I couldn't find a way to list the subfolder of the shares (only the top folder of each share is shown).

This explains why the authentication box appears when a machine is typed into the TI file name boxes (such as \\Win10-64Bit\). The IPC$ connection to Win10-64Bit needs to be established before the share name can be added to the path. This also gives TI the authentication credentials it needs to perform backup and restore operations.

I found that TI disconnects the IPC$ connection after any backup or restore operation is finished. The disconnection even happens if the backup or restore operation fails. I saw this after I tried a backup operation when I had manually made the IPC$ connection before starting TI. I was able to enter the full path of the network backup location and start the backup. However, it failed because TI didn't have the credentials. The IPC$ connection was disconnected after the failure message box was closed.

Mustang,

Thanks for posting your results.  I really do not think that IPC$ has anything to do with this.  I have done some investigating of the True Image app behavior in WinPE and found that the app has issue with network shares and authentication when SMB1.0 is not in play.  As you know, SMB 1.0 has been removed from Windows 10 totally now.

Case in point, yesterday I booted an MVP built WinPE version 10.0.15063 of ATI 2018 ver. 9660.  I found that when configuring a backup task if I used the Browse button to select the destination for the backup I would not see a credentials box prompt until I actually got to the SMB share level.  If I instead tried to type in a network location the credentials prompt was popping up at almost every keystroke.  This included the popup of CredentialUIBroker which would at times display over the top of the ATI credentials prompt.

The above would occur even if I successfully logged onto the device and had been given the connection successful message from the credential prompt of ATI.  If I attempted to enter credentials in CredentialUIBroker that result was nothing at all.  Like it had suddenly just stopped working.  So I would just dismiss the prompt window.

I also found that if I used the Browse button to navigate to the share folder, was presented with the credentials prompt, and successfully logged on, then entered a filename for the backup file, clicked on Next, I got an error message that I did not have sufficient privileges to access the location.  This persisted throughout many attempts so finally I decided to close ATI completely, restarted it, and then I was able to setup the backup task to the share without being prompted for credentials telling me that the connection had been successfully authenticated the first time but ATI was having some issue with it.  A bug it seems.

I verified this same behavior on a more recent build of WinPE with ATI 2019 just to make sure it was not just the older version.

I ran some net view and net use commands during these same sessions and copy/pasted the results in a text file which I have pasted below:

Microsoft Windows [Version 10.0.15063]

X:\windows\system32>net view
Server Name            Remark

-------------------------------------------------------------------------------
\\BOBS-DESKTOP         Personel PC
\\FREENAS              FreeNAS Server
\\RT-AC3200-76B0       RT-AC3200-76B0
\\TNAS-00737A          TNAS-00737A
The command completed successfully.

X:\windows\system32>

_________________________________________________________________________

Microsoft Windows [Version 10.0.15063]

X:\windows\system32>net use \\192.168.2.104
System error 58 has occurred.

The specified server cannot perform the requested operation.

X:\windows\system32>net use \\192.168.2.100
The command completed successfully.

X:\windows\system32>
_________________________________________________________________________

X:\windows\system32>net use \\RT-AC3200-76B0
System error 58 has occurred.

The specified server cannot perform the requested operation.

_________________________________________________________________________

X:\windows\system32>net use \\TNAS-00737A
The command completed successfully.
_________________________________________________________________________

X:\windows\system32>net use \\FREENAS
System error 58 has occurred.

The specified server cannot perform the requested operation.

X:\windows\system32>

Notes:

1. First net view command run after closing ATI and about a 1 minute wait.
2. First net use \\192.168.2.104 command run after ATI reopened and credential authentication made to share on device, FreeNAS server.
3. Second net use \\RT-AC3200-76B0 command run at device WD Mybook connected to router via USB.
4. Third net use \\TNAS-00737A command run at device TerraMaster NAS not having an authenticated credential connection made yet.
5. Forth net use \\FREENAS command run at device FreeNAS server after authenticated credential connection made to device.

As you can see net view shows all networked devices.  IPC$ does not show and never did at anytime during this session.  I suspect had I tried to map a drive letter or run a command at IPC$ that would have invoked it.

The above confirms that only one connection per share at a time can be made.  I did some research on net use error 58 and found it is related to authentication problems with SMB versions 2.0 and up (Windows SMB 2.0 enables SMB 3.0 in Windows 8 up because they share the same network stack).  So this leads us back to the permissions at play again with all of this.

On another note, share connection in Windows and WinPE depend on all devices being on the same network.  For WinPE the device is the user of X:\.  So X:\ becomes a machine/device on the network and is displayed in net view as the machine which is booted  from X:\ which in the case above is \\BOBS-DESKTOP.  If the share is on another network or was created on another network then Error 58 will result in attempts to connect.  This scenario is a very remote possibility especially in a home LAN.  

The tests I made were using TI 2019 WinPE media. The connection is definitely made using IPC$. You can see that by making the connection from the TI 2019 GUI and going back to the command window and entering net use. You will see an IPC$ connection.

I re-tested using TI 2018 WinPE media. The results are different. I agree that IPC$ is not being used. I could use the file name box instead of the Browse button. The authentication box popped up after entering \\ComputerName\. The connection succeeded and the shared folders showed up above. Double clicking on a shared folder showed no subfolders, but the authentication box popped up again. The connection succeeded again and the subfolders showed up. Double clicking on a subfolder made the tib files show up. I was able to select a tib file and continue. I agree the TI 2018 media is somewhat buggy. It is much better in TI 2019 WinPE media using the IPC$ connection method.

After reading the last few posts, I did another try using the WinRE media.

After booting, I tried the net command without drive letter mapping.

net use \\NASbox /user: ... fails
net use \\NASbox\ /user: ... fails
net use \\NASbox\IPC$ /user: ... fails
net use \\NASbox\folder /user: ... succeeds

Running net use shows OK for the folder.

I can then run net use \\NASbox /user: ... and it succeeds,
and running net use then shows OK for \\NASbox\IPC$ as well.

After I get the success on the net use command, I can run ATI and access the device as a NAS as expected.

Bruno,

Thanks for that feedback, at least maybe you have found a usable workaround that doesn't require a lot of steps to give you access.

Mustang,

Thank you as well.  I am going to give my 2019 WinPE another go.  I want to make sure the behavior is the same still.  I will say that the 2018 version takes around 1 or 2 minutes after boot to have all network devices available.  Best to use net view to see that all are available before attempting to go further.

Ultimately, if Bruno could type the full path in the GUI, it might work.

But, basically, at least in 2108 rescue media built on winpe, it is trying to get him to authenticate after the very first / in the path and won't let him get past it unless he goes the net use method first.

Bruno, I've lost track but what version of the adk do you also have installed? At this point, you could test updating the adk to the 1809 version and see if it has any change in behavior or not.

Bruno, I'd like to try something else if you're game too. I sent you a PM. 

Enchantech you may have something there. When I created my video with 2018 winpe, I cut out like 3 minutes just waiting for the PE OS to load on my VM. 2019 winpe is booting way faster for me. Im gonna time them back to back for comparison though, as it seemed to be significantly longer for 2018 winpe to boot the other day and that was from a thumb drive too.

Bruno,

I believe I have a fix for this issue for you.  Send me a PM if your interested.

Enchantech, PM sent.