Home Suggestions and Feedbacks

INFO CODE 4101 error when attempting to backup to network/UNC path

Good day: Attempting to backup to network/UNC path and though I can see the folder when selecting the desination, it asks for network username/password in a pop up window. After entering that information, it appears to attempt to begin saving the file and then fails with INFO CODE 4101 error. Any thoughts?



  • I have the SAME problem here. This is exacatly what I get as well.  I was able to do my initial backups with the previos AOMEI 1.6 version.  But as soon as I downloaded and installed 2.0 version, this started happening.  It fails to create the file....this did not happened before and I am 99 % certain that its due to the version change, because nothing has changed on my end.  Please, can someone provide us with a solution to this, would greatly appreciate it. I was loving the product before this happened. 


  • Hello,

    Please check:

    1.Verify you have sufficient privileges to write to the location.

    2.Verify the destination can be accessed in Windows.

    3.Try to back up to a local device if it fails to write to an external drive or network destination.

  • I have exactly this problem. I successfully did a System Backup to the same NAS drive and folder, but now when I try to do two other Partition Backups, it creates a folder ("My Backup"), says it is writing the first 96Mb, then fails "4101".

    The privieges are correct 9it creates the folder within the NAS folder, and successfully wrote the entire System Backup just before), the destination is visible, readable and writable  in Windows Explorer, and I don't have enough space anywhere else. I bought this 8Tb Synology NAS drive explicitly for doing these backups, but AOMEI won't do them!

    I don't mind upgrading to the Pro version if that is necessary, but I see that only covers 2 PCs and I have 4 to backup (they are in a Network driving my flight simulator). In any case, if the free version can successfully create a System Backup, and create the folder for a partition backup, why can't it actually then do the backup? It makes no sense!


    Pete Dowson

  • Hi Pete,

    We are so sorry for the problem you
    encountered this time. First, good news is that we did some improvements
    to avoid this error in the next version and it will be released in a
    few days. Please visite our site to check the updates at that time.

    I want to clarify what other reasons could cause this error. The
    reasons may be that the IP address changed if you backup to NAS or the
    path of directory where you save the backup file changed. 

    Best Regards,
    AOMEI Support Team

  • Thank you for replying Kim.  As I mentioned on my earlier post, I've never had this problem prior to Version 2.0.  I will be waiting for the next version release in a few days as you stated.  Thanks so much!

  • edited July 2014

    Having same problem with version 2.0.1.  As of today (July 26), there isn't an update available.  Also sometimes get "unable to connect to network drive".  The network drive is shared with "Full Control".  I can create directories, make files, and write to them on the remote computer via Windows without problems, but can no longer back up to the remote computer since upgrading from version 1.6.  Are any solutions expected soon?  Is it possible to download version 1.6 from somewhere?   Thank you.

  • edited July 2014

    Uninstalled version 2.0.1, searched web for version 1.6, and installed it.  Problem solved... 

    No more 4101 "Failed to create file".  No more "Program is unable to connect to the network drive".  It now works perfectly every time.

    P.S.  I understood (from a Support Team post here somewhere) that version 2 would be able to backup without splitting into 4 GB chunks.  I didn't see that in 2.0.1.  Is it still being contemplated?

    Thanks for an excellent product (with version 1.6).  I hope you can get the bugs worked out of version 2 soon!

  • edited July 2014

    Was a duplicate

  • edited July 2014

    Was a duplicate

  • Sorry about multiple posts: kept getting "Capcha error" message, but I guess it posted anyway!

  • I too had this problem on this version, but to resolve it (based on the hint support gave before), I switched to using the IP of the server instead of the dns name.        

  • I've just encountered this problem as well. Interestingly I'd already backed up a couple of PCs using Backupper Standard 2.2 without a problem.

    I then changed the permissions on the NAS share (a WDMyCloudEX2) from public to private and ensured the user login had read/write permissions.

    I then tried backing up another PC using Backupper 2.8 and hit the problem.

    I HAVE seen this problem at home backing up my SBS2003 server to a Seagate Central using BackupExec 9.1. I fixed that by backing up to a PUBLIC share. So I changed the permissions on the NAS share here back to PUBLIC and it worked fine.

    Interesting! At least it is not the only backup software that can't cope with private NAS share permissions, even when connected using user credentials that have full read/write permissions to the share.

  • Hi,

    To anyone else thats had the same issue, today I had the same issue and found this thread, The solution that worked for me was I changed from using the sharename of the NAS to using an the IP which solved my issue and no longer got this error. Intially I was doing it like this \\WDMYDATACLOUD but then switched to 

    However on my other computer I backed up using the sharename without any issues. I was backing up to a Western Digital Cloud NAS. The share was private and used my login credentials to access it. I know some people like the poster above has had issues with private shares. however for me it worked as public folder and when as private share aslong as your login details are correct. 

    I tried using Acronis True Image intially but for some reason it wouldnt recover the data from the NAS stating it was corrupt hence I got a refund and switched to this blessing of software. 

  • I was having the same problem and i was able to make it work by using the ip instead of the share name as suggested. I am using version 2.80 and backing up to a synology NAS.

  • Regarding "Information code:4101 - Failed to create file"... The workaround that I found that works is using the same username and password for the connected map drive in Windows as the same credentials in AOMEI Backupper. 

  • Hi, it's Oct. 2015 now.  And I am using ver 3.2.  I encountered the same 4101 problem and my workaround is:

    net use x: \\MyNAS\myhome\myfolder /user:myPCusername myPCpassword

    then have AOMEI backup to x: drive.  It will work.

  • I'm experiencing these weird behaviors as well. Worse, they are erratic. This needs to get sorted out.

    Tonight going over network booted from PE disc 3.2 Technician Plus I encountered this...

    Target path \\\z$ fails with 4101 before backup initiates. This isn't even going to a dedicated NAS, this is just going to a Win 7 64bit station over the network.

    So I deleted that NAS path and tried this...

    Target path \\Win7\Backup (\\ComputerName\ShareName) succeeds. The application shows the previous path (\\\z$) while backing up for some strange reason.

    I've also encountered problems trying to target actual NAS gear as well (ReadyNAS).

    I've read multiple posts about multiple errors / codes and every person says this all began AFTER version 1.6

    It would be nice to acknowledge there is SOMETHING wrong and being looked into, rather than just keep telling us all to "check our permissions". I'm sure that's valid advice for some, but many of us are actually technically adept and more than capable to realize there is an actual problem with the software.

  • Solution1:


    Firstly, please check the following items:


    1. You havesufficient permission to read/write to the destination location.

    2. You haveenough space on the destination location to accept the image file.

    3. If you are trying to make afull/incremental/differential backup based on a backup task that already exist,please make sure that backup task is valid. You may run Check Image in theAdvanced menu to check whether it is valid or not. If it is invalid, you needto reload the task.




    If you failed to back up toNAS/Share(network drive), there is one more possible solution you can follow.


    Map the NAS/Share(network drive) as alocal drive in Windows


    You can refer to the screen shot below tomap your network folder.



    After mapping the folder successfully, thenyou can back up to the directory of the network folder just like backing up toa local location.

  • Sigh... Okay let's try this again...


    1 Yes permissions are correct

    2 Yes space is sufficient

    3 Yes task is valid


    Doesn't apply to my stated scenario, BOOTED from PE disc.

    The 3.2 version is behaving erratically. My workaround was to switch from IP to DNS path. Just a couple posts above mine their workaround was to switch from DNS path to IP. What works for one works the opposite for another? Does that sound normal to you?

    This is erratic behavior and not something I want to encounter in a crisis situation. I used version 1.6 for nearly two years on the same systems with none of the issues that DOZENS of people are posting questions about for version 3.2.

    I'm just in testing phase with this release right now, I'm calm, no crisis. My initial test of a full backup/verify/format/restore of Server 2008 R2 Enterprise resulted in boot failure. I had to Fixmbr / Fixboot / rebuildBCD before I could get it to boot again.

    This version needs an overhaul.

  • Sorry for the late reply. Is that all ok for you now? Can you do the backup successfully?

  • No. Does not work 2 years later in Version 4.1.0. Same problems.

  • NO!!! Version 4.6.1 does not work either in January 2019.
    ALL permissions are correct.
    Plenty of room.
    Saving to a mapped network drive that obviously is recognized by AOMEI, as it does create a folder in the target location, then it just gives the Error 4101.
    The first post in this discussion is dated May 2014; that is nearly five years and several versions ago.
    The problem is obviously with AOMEI and not with the users.
    I am getting this same error on four different machines.
  • Had the same Problem today. Solution was the suggested use of IP instead of FQDN when connecting to the NAS.
  • @MUV, What error situation did you get when you use FQDN to add the NAS? Could you take a screenshot so that we check?
    In addition, how do you connect your network drive?

Sign In or Register to comment.