Bootable Media Doesn't See Acronis Folder

I haven't seen this behavior yet.  So basically,  you're saying you can get to the root of your mapped drive, but as you step through from it into deeper folders, it does drill into deeper folders up until just the one level before where your backup folder is actually located and doesn't show that particular folder, but all the other folders at the level are displayed?  That would be really odd unless the permissions on that folder have been modified recently, but even odder if they did and it worked in 2016 and not 2018 or 2019.

Are you using the Linux default rescue media or WinPE or WinRE rescue media?  Try the WinRE if possible just to see if it's the same or not.  Also, if you haven't checked out the MVP custom WinPE media builder, try it too - makes it much more enjoyable to use with a native file explorer and some Windows-like menu's that allow you to use the rescue media with a more user-friendly environment.  That way, hopefully, you'll also have the best Windows drivers and compatibility for the network - especially if you've enhanced SMB security like many of us have be disabling SMB 2.0 and lower recently.

Also, since you're on the domain, when you connect to the share in Acronis are you using:

domain/username      instead of just         username

I'm assuming so since it's working in 2016 as expected, but just to be sure.

So basically,  you're saying you can get to the root of your mapped drive, but as you step through from it into deeper folders, it does drill into deeper folders up until just the one level before where your backup folder is actually located and doesn't show that particular folder, but all the other folders at the level are displayed?  

That's correct. The mapped drive on that server is D. Within that are about 6 folders, one of which is Acronis Backups. It sees the other 5 but not that one, but it always sees that with Acronis 2016 bootable media.

Are you using the Linux default rescue media or WinPE or WinRE rescue media?  

I'm using the standard one I'm sure, just the downloaded one listed under Bootable Media when looking at the TI version in my downloads. So I assume it's Linux. How do I best get the WinRE one? 

Also, since you're on the domain, when you connect to the share in Acronis are you using:

domain/username      instead of just         username

Correct. Otherwise I'd never make connection. 

Try the windows PE method as a test to see if it's the same. In 2019, go into tools >> rescue media builder and selected the advanced option. If you download and install Windows 10 ADK it will build winpe for you. If not, it will attempt to build it with that systems WinRE (recovery environment) instead.

Have you tried mapping directly to that folder as well? Maybe create a new share alias for that specific folder and see if it can just map straight to it too?

OK, I tried the WinRE solution by creating one from Acronis TI 2018. I didn't download and install Windows 10 ADK. When I booted to it it took much longer to boot than with the Linux bootable media, Acronis 2016. And then when I tried to access the shared folder on my network it never came back asking for credentials or doing anything. I basically couldn't even get it to work at all. Maybe I'm missing something.

The one downside I can think of with winre over winpe is it takes all the system drivers and packages then in. Default WinPE and the default Linux recovery have a very small subset of generic drivers that load pretty fast.

Someone else just had a response that the WinPE is having trouble accessing the share in their NAS too so I will have to check mine tonight. As a workaround, they used the command prompt to map the share with net use and could access it and backup .maybe try that for now too?

OK, I built two different rescue media (each on its own separate thumb drive).

Test 1:  Default WinPE using Windows 10 ADK 1809 (10.1.17763.1).  I also supplied my custom Killer Ethernet NIC driver and the most current IRST driver for my NVME drives.

Results:  no issues mapping to my NAS backup share.  However, I will note that I manually typed in the NAS IP, but it automatically showed me the available shares and I picked the one for my Acronis backups.  I was then prompted to enter credentials, which I did and tested the connection with success.  I then connected with success.  

The screen would not move forward.  I needed to enter a backup name in the path... I used test.tib.  I could then continue and it let me backup.

Notes:  after connecting to the NAS this way, I used "net use" in command prompt and received:  

Status       Local     Remote                    Network

-------------------------------------------------------------------------------
OK                     \\192.168.1.100\IPC$      Microsoft Windows Network
The command completed successfully.

I noted that I could use net use /DELETE * and that would remove it, but then I could not create any shares to the NAS again this way.  NO matter if I tried to use Net USE or the A43.exe network drive mapping, I could not connect to a different share.  I don't know what the IPC$ is, but seems like when it's used, I can't map again after disconnecting it.

X:\windows\system32>net use Q: \\192.168.1.100\acronis_nas /USER:xxxxxxxxxxx * /PERSISTENT:YES
Type the password for \\192.168.1.100\rbd_acronis_nas: xxxxxxxxxxx
System error 1312 has occurred.

A specified logon session does not exist. It may already have been terminated.
 

Alternatively, I rebooted and booted back in and this time, I used a straight net use command and could easily map the share this way and delete and map it and delete it.  I could swap back and for with net use and A43.exe to map the share very easily. 

Overall, connecting to the share was pretty easy and worked as expected.

Test 2:  Default WinRE using Windows 10 ADK 1809 (10.1.17763.1).  I also supplied my custom Killer Ethernet NIC driver and the most current IRST driver for my NVME drives again.

Results were exactly the same as ADK WinPE.  Connections worked exactly the same.  I didn't have any issues connecting from the Acronis GUI or Net Use or A43.exe, other than the issue with not being able to connect again after using the Acronis GUI in that same session due to the result of

 

System error 1312 has occurred.

A specified logon session does not exist. It may already have been terminated.

My only notes for using the GUI in Acronis to connect to the NAS - it really works best if you type in the IP address of the NAS and the full path to the specific share you want to use.  Be sure to include a backup name with .tib extension as this wasn't blazingly clear as I assumed that would be the next step after trying to continue, but could not continue until I gave it the backup file name.

Personally, I think that mapping the share with either A43.exe or using net use was more intuitive than the Acronis GUI though.  Since I usually use custom WinPE built with the MVP tool, A43 is easy to launch and use for this purpose, and then Acronis can just use the mapped drive letter to continue.

IPC$ Look HERE

Thanks Enchantech. I found a similar article from Microsoft soon after too.

I guess I'm just unsure why the rescue media connects to it instead of mapping a drive letter and of one has an advantage over the other or disadvantage?

Also, why disconnecting it with net use prevents mapping any drive letters to that share during that winpe session again?

Could that be causing some of the other NAS devices to have issues connecting which could be resolved with mapping the shares as a drive letter instead?

This forum explains the one time ability to enter credentials for the IPC$ share per logon. Interesting!

https://serverfault.com/questions/443276/how-do-i-reconnect-to-a-unc-share-using-different-credentials

OK, someone please help the uninitiated here. What do I gain with rescue media like WinRE or WinPE vs the normal Linux bootable media that I've always used? Until until recently everything's been fine with it, and I can't imagine why when I point to a network share that has multiple folders in the share that one of them is missing in later versions of it (2018 or 2019). Yet with Acronis 2016 bootable media it always shows up. 

Joel, I can't find one post again, but it was mentioned by a mod that the underlying version if Linux was upgraded in recent builds of the rescue media. Although this is usually good (newer drivers) in some cases older hardware and or settings take a hit - this was found with a NIC in that thread as the newer version lost support for an older hardware of that manufacturer but gained support for a newer one that wasn't previously compatible.

  Also, the Linux version has no support for Newer NVME PCIe hard drives which normally come from vendors in RAID mode, even when there is just one.

Basically, winPE is more modern (usually) as it gets updates by Microsoft with each new version of Win10 and has a great base driver pack. It's also customizable with your own drivers that you can add, and with tools like the MVP builder, can be customized to add things like a file explorer, start menus, web browsers, etc.

The upside to Linux media is it's open source and can be distributed as a prebuilt iso. WinPE licensing requires it must be built on a fully licensed OS so can't legally be distributed prebuilt. The process to build it is fairly straightforward though.

If the Linux version is working in older versions but now is not, it's either a bug and you should open a support case. Or, the newer build of Linux lost something that was in older version and should be reported anyway. Bugs do exist in rescue media too. Use the older revue media If it's still working. The images will be fine and are compatible.

Personally, WinPE support from Microsoft, having a Windows PC that I'm backing up and being able to customize the recovery media has shown me it's much more versatile, especially when so many new systems have NVME hard drives and custom storage controller needs that are not available in the Linux rescue media.

I think that the OP has a security issue with the share.  It is likely that there is something different about the share permissions or something in Group Policy possibly that is in play.  Might even be a firewall setting or rule.

IPC$ is a special share that is used to facilitate inter-process communication (IPC)

That is, it doesn’t allow one to access files or directories like other shares, but rather allows one to communicate with processes running on the remote system.

Based on the research, certain versions of Windows allowed one to authenticate and mount the IPC$ share without providing a username or password. Think Windows 98 and earlier.  Such a connection is often referred to as a NULL session, which while limited in its privileges, could be used to execute various RPC calls and as a result obtain useful information about the remote system.

You could use commands net use \\IPAddress\IPC$ "" /user:"" to do the map.

To confirm that the sessions are mapped, enter this command at the command prompt:
net use

You can leave off the ""/user"" and only guest or public shares would be viewable.  If all you get back is the \\IPAddress\IPC$ then there are no such shares on the network. 

If you delete the IPC$ share then you will loose communication with processes on the remote system.

If you delete the IPC$ share then you will loose communication with processes on the remote system.

Yes, this seems to be the case.  However, that appears to be permanent for that launch of the WinPE.  When you delete Net Use shares with a specific volume letter, you are able to re-add them again, delete, re-add, over and over.  But for some reason, once you delete IPC$, then what I experienced was that I could not use Net Use to map any other volumes on the NAS during that WinPE session.  I would have to reboot and launch WinPE again, and then I could map volume letters on the NAS with Net Use or A43.exe.

Not a bug, or a bad thing necessarily, just noting the behavior of how this works in Windows PE.

-----------

As for the security / permissions issue, it's possible there is a problem.  But if it worked (and still works) with 2016 rescue media, but not in 2018/2019 rescue media to the same share, what changed on the rescue media so that the old versions do work, but the new versions don't to the same share?  It's odd that 2016 can connect to it, but won't accept the same logon credentials with 2018/2019 in this situation.

I also wanted to cross-reference another new 2018 thread from BrunoC into this thread.  2018 just released update 5 not long ago so it's possible this behavior is new, not just in 2019, but the current version of 2018 rescue media.  He's also stating that he cannot authenticate to the NAS share in the Acronis GUI with rescue media (WinRE made), but did have success with using a manual Net Use command in it to map the NAS drive with its own volume letter.

***REFERENCE 2018 thread:  Rescue Media is refusing to let me access my NAS by BrunoC***

https://forum.acronis.com/forum/acronis-true-image-2018-forum/rescue-media-refusing-let-me-access-my-nas

To be honest I think the issue is the SMB 1.0 issue.  It makes sense to me that MS leaving SMB 1.0 deprecated from the most recent version of Windows would also do it with WinPE/RE. 

How about testing this out?  To do so you will need a WinPE version prior to 1709.  Build it and see if that makes a difference.  I would but I do not have the time at present.  If that works to to fix your issue then I think that would say I am correct.  If not then it may well be related to TI.

Yeah, unfortunately, it will be up to Bruno or the OP here to test if they can.  I can't replicate any issue with actually connecting to my NAS with current rescue media and current ADK.  I'm able to authenticate to all of my NAS shares in the Acronis rescue media GUI, as well as with net use and A43.exe. 

Ok, I thought I would try net use via Windows command prompt on a Windows 10 1809 booted system.  I have a new NAS I added to my system over the Holidays.  It has a Public share and Authenticated shares.  If I run net use \\IPAddress\public the return is command completed successfully.  If I run net use \\IPAddress\share on the Authenticated share I get a 1219 multiple connections error.

This indicates to me that security of SMB 2.0 and above are in play.

I also found that I could not type a password in the command prompt when prompted.  The keyboard was unresponsive except for the Enter key which of course would display the 1219 error. 

Just FYI - the password part has no interaction on screen - you won't see the cursor or anything move. 

Once the IPC$ share is mapped, you can't map any other network shares (even with the same credentials) because it sees that as attempting to use two different accounts - even though, you are trying to use the exact same credentials and account again.  Where, when you instead use volume letters, you can not only map multiple shares (as long as all are using the same credentials), but you can also disconnect existing ones and map new ones.  

In WinPE, basically, the work-a-round is to just reboot the rescue media and start again if IPC$ has been mapped by True Image and won't connect.  This is why I'm liking the option to just use net use with a volume letter or doing this with A43 in the rescue media instead of the Acronis GUI.  For most people, probably not an issue.

But, if the IPC share is not accepting credentials at all (which seems to be the case for BrunoC)- even when it is the first attempt to the share, then yeah if that is based on added security, it no longer is helpful to end-users the way the WinPE is mapping the drive.  We either need a fix that ensures that they can successfully connect to the share with the current method, or change the behavior in the rescue media GUI and map volume letters instead of using IPC$ as the default - (like how A43 handles it).

OK, last update from me on this.  For those who are entering credentials and can't connect to the NAS in WinPE or WinRE, definitely open a support case and submit feedback.  

I just did more testing with default Linux media, WinPE and WinRE media using the current version of rescue media built with Acronis 2019 14690 (same as last night)

In all 3 instances i was able to enter my NAS share (\\192.168.1.100\acronis_nas_backps as an example) and was then prompted to enter a user account and password.  Upon doing so it said "test successful" and then I proceeded and it said "connection successful".  From there I had no issues giving it a backup name such as test.tib (make sure you add the name in the path as it's not always clear that is what it's waiting for after you've authenticated) before you can click "next".

As for the ICP$ connection, I found that I could indeed delete it with Net Use and then could map the share manually with a drive letter if I wanted to go that route instead.  So it was not a one time only thing.  Also, if I deleted all net use shares, then I could go back into Acronis and it would remap the ICP$ share again without needing credentials (usually), but if/when prompted, it took them.

Long story short, it worked fine in all of my tests.  The one new thing to note, as Bruno found.. if you use net use to map a drive letter (and the same applies if you use A43.exe), after the backup completes, net use still shows the drive letter mapped, but it has actually been disconnected.  Basically, I would have to use net use /delete * and then map it again, if I wanted to navigate the share again.  This looks like a bug with WinPE as net use said it was mapped, but then I couldn't use command prompt to get to the mapped drive letter without deleting the mapping and re-adding it again.

So, for those who can't authenticate, or can't see the share, it probably is a mix of security or permissions that has changed.  I'm using a WD-MyCloud 4TB and all is working.  Perhaps it is only certain devices or settings that are causing authentication issues in WinPE rescue media, but no idea how to hunt down the cause without getting higher level Acronis tech support involved.  In my own experience and testing, all 3 media formats worked as expected and did the job connecting to the NAS well.  I'm also no longer concerned about the ICP$ vs the drive letter share - just learned that you can only have one or the other at any given time and by attempting to connect to the share through the Acronis GUI, the ICP$ share will be there first/already.

Bobbo_3C0X1 wrote:

Just FYI - the password part has no interaction on screen - you won't see the cursor or anything move. 

Once the IPC$ share is mapped, you can't map any other network shares (even with the same credentials) because it sees that as attempting to use two different accounts - even though, you are trying to use the exact same credentials and account again.  Where, when you instead use volume letters, you can not only map multiple shares (as long as all are using the same credentials), but you can also disconnect existing ones and map new ones.  

In WinPE, basically, the work-a-round is to just reboot the rescue media and start again if IPC$ has been mapped by True Image and won't connect.  This is why I'm liking the option to just use net use with a volume letter or doing this with A43 in the rescue media instead of the Acronis GUI.  For most people, probably not an issue.

But, if the IPC share is not accepting credentials at all (which seems to be the case for BrunoC)- even when it is the first attempt to the share, then yeah if that is based on added security, it no longer is helpful to end-users the way the WinPE is mapping the drive.  We either need a fix that ensures that they can successfully connect to the share with the current method, or change the behavior in the rescue media GUI and map volume letters instead of using IPC$ as the default - (like how A43 handles it).

FYI - I know all of this already.  The point I was trying to make was that Windows Network Security is at play here.

The IPC$ share is an Administrator share.  You cannot logon to this share nor can you modify it's credentials.  It's sole purpose is to share resources remotely.  If you disable it you loose connectivity to the remote device which you have already proven.

SMB version as well as Device Discovery play a big part in share access these days.  Example, I have 2 network devices serving as NAS's.  One of them uses NetBIOS for Discovery via a Web based interface.  I can view that devices shares using Net View \\IPAddress.  If I attempt to logon I get the share access denied account multiple logon message and reason is that the I have mapped the share in Windows Explorer for access during any active Windows session.

Conversely, I have a FreeNAS sever with SMB shares.  This device does not use NetBIOS for Discovery so if I attempt Net View \\IPAddress I get "The network path was not found" message.  If I use Net View \\hostname I can see the device and its shares.  The same holds true with Net Use command. 

The whole point here is simply that authentication and permissions play a big part in access and viewing network devices and shares.

Joel,

My suggestion to you for your issue would be to use Windows Explorer from your client to access this missing folder.  Once you have it in view in Explorer right click on it and select Properties then click on the Security tab. 

Make sure that the client machine user whom is attempting share access is listed with Modify, Read & execute, List folder contents, Read, and Write permissions all checked.  If they are not then you will need to set these permissions for the user on the Domain server for share access.

I suspect this is because of older version of TI media were still using SMB 1.0 and NetBios for authentication and discovery whereas newer version are not any longer.

I've now seen this multiple times. I'll boot with bootable media created with TI 2018 or TI 2019. I have a networked share drive folder that contains several subfolders, but the critical one here is Acronis Backups where all of my recovery TIB files are. I'll Browse to get to the path, enter the credentials (we're on a domain), and it'll connect to the high level folder just fine. Then the one folder I need, Acronis Backups, doesn't show up.

I haven't read this whole thread so this may be a duplicate, or otherwise meaningless, comment.

I've seen this problem even in the installed  copy of ATI (in the Add existing backup function).  If a directory on a NAS has a file or subdirectory that cannot be accessed with the given credentials ATI stops processing the direcory.  (In my case it was a Recycle subdirectory that could be accessed only by the NAS Admin account.)  ATI would get an error reading the directory and display nothing in it - even if it had authority to access most of the entries in the directory.

I could find no solution other than allowing non-Admin access to the subdirectory or removing it altogether.

I had the exact same situation as the OP while I was doing a disaster recovery exercise: I could not see the NAS subfolders where my .tibx backup files are stored.

"I have a networked share drive folder that contains several subfolders, but the critical one here is Acronis Backups where all of my recovery TIB files are. I'll Browse to get to the path, enter the credentials (we're on a domain), and it'll connect to the high level folder just fine. Then the one folder I need, Acronis Backups, doesn't show up. Al the other subfolders do though."

I solved the problem after I realized that the Acronis software that backs up my workstation every night is using different credentials than I normally do to open a session on my Windows workstation: "MyName" / "pwd1". Somehow, during the installation process of my ASUSTOR NAS I have created a local user account bearing my full email address and a different password: "MyName@XYZ.com" /  "pwd2". The Acronis SW has since used these local credentials to log on to the NAS, create its backup subfolder "\\MyNAS\Home\AcronisBackups\" and copy its files.

After that epiphany, I booted again from a my Acronis USB rescue media, then I hit Restore, set up the network to use the eth0 interface (could have used WiFi), entered the network address of my NAS (\\192.168.2.12\) in the File search field, got prompted for credentials and entered those of my local NAS user: "MyName@XYZ.com" /  "pwd2" and Ta Dam! the elusive backups were revealed.

What gave me the idea of the dual credentials was that Windows Explorer would display different contents on my NAS depending on where it was launched from.

• From "Acronis Cyber Protect Home Office": / Backups / This computer / down arrow /Open location, I could see my subfolder "\\MyNAS\Home\AcronisBackups\" and its content.
• From a share mapped from a terminal session using my normal Windows session credentials I could see "\\MyNAS\Home\" but not the rest.
• When I copied different test files through each channel they were not visible through the other one. On the same screen, side by side. That felt creepy.
• From a Windows session using my secondary (spare) admin account I could only see "\\MyNAS\Home\".

I hope that this helps someone.

Dear Louis-Georges Lefebvre,

Thank you very much for sharing your experience and a possible solution.