True Image with WinPE cannot access Windows 10 shares
I originally reported this as a problem back in January and got the reply 'Oh its a known Windows issue' it will be fixed with Windows 10 March update.
BUt here we are in May and after MArch and April Windows updates and 6559 and 6569 TI build updates the problem still exists.
Downloaded and installed buid 6569. Buildta WinP USB stick using the tool in True Image and booted it.
1. Entering \\10.0.0.227 (my Windows 10 laptop) into the restore browse path opens up the credentials window – but fails to validate credentials.
2. Entering \\10.0.0.8 (my Seagate Personal Cloud NAS) into the restore browse path opens up the credentials window – but fails to validate credentials.
3. Using a ‘NET USE’ command in the WinPE command prompt window to validate credentials works for both 1) and 2) above works.
4. Once credentials have been validated by 3) above then access is possible either using the UNC or the net use drive letter.
Anyone else getting this problem, or managed to get Acronis to accept that it is a problem?
Thanks - nothing there helps - already checked them.
Not that I need 'hlep' per se, since I can recover, if necessary, using the 'NET USE' workaround. I would just like some reassurance that Acronis are actually working on this issue - my attemps at dialogue with tech support have been very unfruitful, they seem reluctant to admit there may be issues, even though the latest build for MAC states that issues with shares were fixed _I know that is MAC and I am talking abt WinPE - but it seems coincidental and may be that SMB shares are they issue.
Allan, the only other real option here is to use the Feedback tool in the ATIH GUI Help section and make your comments directly to the Acronis developers.
I suspect that some of this will be attributed to WinPE itself as that is providing the underlying OS support that creates the networking capabilities here, and this in turn is coupled to a broad spectrum of potential networking partners to connect to.
Well - that could be worth a try. Thanks.
I wonder if others are seeing the same symptoms.
You need to use the command prompt in WinPE and connect to the share using netuse commands.
Alternatively, I usually just type in the UNC path instead of trying to navigate it and when prompted for credentials, I put in the workgroup/username (workgroup is usually the computer name of the system hosting the share unless this is an Active Directory envionment).
Example:
\\my-pc-name\share
username: my-pc-name\username >>>>> password
As you will see from my original post - yes I already use the 'NET USE' command.
Typing in the UNC does not work - the credentials prompt does open, either using the share name or the IP address - they both fail to validate credentials
I will have a look at the format of credentials further tommorrow - it slate now
Allan
The Win10 update mentioned was actually for Win10, not Acronis. That update did seem to bring stability to Windows 10 homegroup shares as there were Windows issues where reboots of one system (source of destination) would prevent the share from working if the other system was also not rebooted.
What is the version of the Windows 10 ADK you have installed in control panel - the intiial version was the problem from Microsoft. You need to ensure that you have the ADK for Windows 10 v 1511 (https://msdn.microsoft.com/en-us/windows/hardware/dn913721.aspx). I don't have it on this laptop to give you the exact version that it shows up in control panel as though.
I have not had any issues using Acronis WinPE with this version of Windows 10 ADK, or any WinPE created with this ADK (All WinPE is based off the Windows ADK - Acronis is just a application that adds itself to the base ADK and launches the Acronis.exe)
Have you tried by IP as well? What are you specifically putting in for your user credentials? Assuming this is a Windows 10 workgroup system, you must put in
\\computername\sharename to the specific folder for the backups - perhaps folders paths between the root of the drive and the share are not fully parsable (for instance, you can have the root shared, the next folder denied, but then the next folder below that shared out. Try mapping the exact share or full path as well - remember that share permissions and local folder/file permissions can be different too.
Second, when prompted for credentials, you must enter the computer name (this time without \\ though) followed by \username using an account on the computer that has modify access to the share.
I use this for an SMB share with a USB drive attached directly to my Asus AC-1900 router as AC-1900\username and it works fine. I also use this on my Windows 10 x64 Education laptop, a Windows 10 x64 Pro Desktop and a Windows 10 x64 Home netbook in my personal environment and on several Windows Server 2012 R2 servers at work - all without issue using the v6027, v6559 or v6569 default bootable Linux media and the Windows 10 ADK for v1511. In my workgroup though, it is always computername\username and in my Active Directory environment, it is always domain\username
I believe I have the latest WIn 10 SDk - but will have a look tomorrow
Allan
OK -
I used 'DISKPART' to clean my USB stick.
I uninstalled, downloaded new and reinstalled SDK - it was the same version. CVOntrol Panel/Programs and Features shows 10.1.105860.0
Allowed ATIH to create the WinPE and booted into WinPE. Using 'VER@ shows 10.0.10586.
In ATIH clicked 'recover'. Window opens with nothing to select on right hand side. Click Browse button.
Type in \\10.0.0.225\ at this point credentials window opens. enter annwn\username and password and - yeah I am in.
Equally tried \\annwn\ and ditto as above.
So I can access my laptop shares.
NOW - try to access my Seagate Personal Cloud NAS drive. In full windows I can access this by typing \\personalcloud\folder - credentials window opens. Equally in Full Windows I can enter \\personalcloud\folder and credentials window opens.
In WinPE using either IP or name the credentials window does not open. However if I use 'NET USE' there is no problem accessing the NAS drive
Allan
Once you've connected the share with netuse and assigned a drive letter, try just entering the drive letter in the recovery path such as D:\ or whatever you mounted it with netuse as. The session should already be establshed once the netuse command has been used in Windows.
Have you tried connecting the share without first using netuse as well to see if you then get prompted in Acronis?
Thanks -
If I set a shared drive letter with 'Net Use' then in ATIH under WInPE:
Using the shared drive letter works or entering UNC path in the form '\\10.0.0.8' works - no credentials are requested it just works.
If I reboot and do NOT create the share then using the IP does not work - no credentials requested
Your NAS devices not being a Windows OS based device must use a mapped drive letter for access unlike your laptop which is a Windows OS based device. Netuse is required for share access on non Windows OS based devices when using WinPE.
Great - that explains everything - pity Tech support couldn't have said that - it would have saved a lot of time
Thanks All
Is there any way to automate the mapping process when starting the recovery? Can I perhaps integrate a batch file that maps the backup-folder of my NAS?
Hello Thomas, see post https://forum.acronis.com/forum/118416 and in particular post #4 where Bobbo has suggested a way to integrate the mapping of your NAS folder.
First you need to create a folder to use as working space. Mine is 'h:\wimtest'.
Open a command prompt window - running as admin on Windows 10 right click on the 'window icon' and select the appropriate entry.
My USB drive is drive 'i:' enter the following command
Dism /Mount-Image /ImageFile:"i:\sources\boot.wim" /index:1 /MountDir:"h:\wimtest "
Now search for the 'startnet.cmd' file in the 'h:\wimtest folder' - it needs to be edited.
Add the following line as the first line
net use z: \\10.0.0.8\public /user:xxx yyy
note that xxx and yyy are the user name and password required to access the NAS drive - on my Seagate I have to put in the user and password even though the my backup folder is public and does not require credentials. \\10.0.0.8 is the IP address of the NAS drive - it needs to be a static address. Once you have saved the file you need to save the boot image using the following command
Dism /Unmount-Image /MountDir:"h:\wimtest" /commit
Hey Allan,
thank you for this hint. Finally it works, but i had to put the "net use" command at the end of the script, because the network service isn't available, if i put it at the beginning. Thank you very much!
Hey Allan,
thank you for this hint. Finally it works, but i had to put the "net use" command at the end of the script, because the network service isn't available, if i put it at the beginning. Thank you very much!
You are welcome - network isnt up at the start is just down to how quickly your system comes ready. I wasn't sure if, by putting it at the end, the share would be established by the time TI is ready.
You can add
ping -n 15 127.0.0.1
the '15' is a delay of 15 seconds and 127.0.0.1 is the local port of your pc.
Hey Allan, that is exactly what i did. But i pinged my NAS to be sure, it will wake up, if it is still in Standby. Everything works fine now.