Problem connecting to FTP server
I have two NAS devices with FTP enabled on both. Acronis TI can get to one of the servers with no problem. It fails to the other with an error 530 - authenication failed. This failure occurs on two different PCs. I can get an FTP connection with server using a browser (Firefox) and WinSCP so I know I have the correct credentials.
I tried following the instructions in the Knowledgebase entry 2465: FTP Log (https://kb.acronis.com/content/2465) but no log was created so I obviously was not successful following the directions. (I consider it entirely unacceptable to expect customers to use Regedit to obtain diagnostic information. I apparently did not add the registry entry correctly and am not about to make matters worse by trying again!)
For what it's worth, the one server requires lower case userids. Does TI mess with the case of the userid in FTP credentials?
The two devices have different names - the default names, but they are different models: WDMYCLOUD and MYBOOKLIVE. (Otherwise my browser and WinSCP would have had the same problem.)
I'll check out that article you mentioned. (More registry hacking. Boo. Hiss.)
Well, I checked and deleted the Acronis FTP entries. (I deleted the SMB entries, too, since on this PC I have no backups directed to a NAS.) I still have the problem. And surprisingly, when I click on "My FTP connections" when setting up a destination for the new backup, an old FTP connection is shown - mybooklive - even though I have no defined backups using FTP at the moment and the Acronis FTP connection records have been deleted from the registry. I did try an FTP backup to mybooklive as a test last week but I deleted (or tried to delete) all reference to that backup when I was done testing.
I scanned the whole registry for "mybooklive" (case insensitive) using RegScanner and found only 2 occurrances - both related to Windows mount points. I scanned my system disk for "mybooklive" and found only 3 hits - all related to a desktop shortcut to the MBL "dashboard" web page. I scanned another internal drive and found no hits.
I have no idea where TI has saved this information and I have no idea if it is causing my problem with getting an FTP connection with wdmycloud, but I should not have any traces of that backup and that connection left.
I'm confused and worried.
Patrick...have you checked Windows Credentials to see if the FTP credentials are stored there?
The Credentials Manager shows no web credentials and a couple very unrelated Windows "generic" credentials (for Office15 and "virtualapp/didlogical" ... whatever that is). Nothing related to Acronis and/or FTP.
Ok. I am m,uch farther in debugging this, but no closer to a solution. I had to install WireShark and get a packet trace of the failure.
First of all, Acronis TI gives a misleading "Connection failed" error message. In fact, TI successfully connects to the FTP server, logs in with the supplied credentials. The server reports that it is at the root directory. (I don't know if this is standard behavior. I think usually an FTP session starts at the user-level directory.) TI then determines the capabilities of the server. Midst the capabilities of the server, it mentions support of the MLST command - the standardized file and directory list command. Up to this point, things are good.
Next, TI issues "MLST /". The server returns a message "550 Can't check for file existence". TI then aborts the connection and reports "Connection failed".
My other (dumber) NAS-based FTP server does not support the MLST command so TI does not issue it. Even though that server also opens at the root directory TI displays the existing subdirectories and allows selection of the correct one.
I have not determined if MLST at the root directory is supposed to work, so I don't know which end is at fault, but I am not happy about this situation.
Which one is giving you the problem - what's the model # and current firmware version? I'll help research it. I'm using a WD-Mycloud WDBCTL0040HWT with firmware v04.04.03-113 and FTP seems to be working fine. Haven't busted out wireshark yet. I inherited this from another Acronis user who got tired of trying to make it work because it was unreliable. I did a lot of WD forum searching and some of these lower end consumer NAS seem to be down-right buggy. Mine ultimately got resolved with a weird work-a-round.
1st, I upgraded the firmware, but that didn't actually fix it. After upgrading the firmware, I then did a "system only" factory restore, but had to do that after the firmware upgrade! If I did it first, the bugginess remained.
It's WD-MyCloud that is giving me trouble - WDBCTL0030HWT (I think). There are 3 2 lines of firmware for the MyCloud line. You have the 04 line; I have the 02 line. As of this afternoon I'm at v02.21.111. (I was at 02.11.140.) I have no idea what the difference between the lines of firmware is except that the installation files of the 04 line are .deb files - Debian, I assume. (The 02 line firmware files are .bin files.) I would try the o4 series firmware, but I don't know if it is possible to switch from one to the other ... and I don't want to brick the drive trying.
If Acronis can talk to your FTP server with no problem then maybe I'll see if it's possible to switch.
Update: I have confirmed that the MyCloud v4 firmware (Gen1) works because it does not claim the MLST command (so Acronis TI does not send it), but the V2 firmware (Gen2) fiails because it incorrectly says it supports the MLST command. I've reported this to WD support but I don't expect much to be done.
I have not seen anything official, but I've read that the Gen1 and Gen2 MyCloud devides have different hardware and cannot run each other's firmware. I guess I I can alsway use more disk space, but for my intended purposes, I bought a boat anchor. Acronis TI FTP will not work with this device.
Bummer! Yeah, I was reading that there's no chance to switch between the 2x and 4x firmware as well. Not sure that's true; perhaps via TFTP or SSH it could be possible, but probably not worth the risk of bricking it completely.
Is there no chance of using SMB instead of, and/or in addition to FTP, or are you limited to FTP for a specific reason? I am running both protocols on mine and functionality is pretty much the same. FTP can be faster (with a good FTP client), but also limited to 2Gb chunks. I'm getting really good speeds over SMB and able to use the default .tib size or set it to something a little more manageable like 10Gb chunks for larger backup jobs.
I'm trying to set up a secure respository for backups with connections open only for the duration of the backup and not usable by other processes on the two endpoints of the connection. Windows' use of SMB (and maybe everybody's use of SMB) seems to have another purpose - to let a public or private share (but not both!) on a server be an extension of a user's local disks. The share is available to all of a users' processes, and, as near as I can tell, there is no way to close the connection as long as both ends stay up. That's very good for most purposes, but not for that secure respository I'm after.
I can, of course, take a backup to a local (USB-attached) drive and then kick off an FTP copy outside of Acronis. That is probably what I will end up doing. I was just hoping I could do it all within Acronis itself.
Might there be some way to tell TI to not issue an MLST command even if the FTP server says it is supported? I doubt there is, but I might as well ask.
Similar thread, but different fix (although since you're running the latest version, probably doesn't help).
https://forum.acronis.com/forum/117092
Try sending DMITRY a PM and see if he responds.
I've PMed Dmitry and I have a WD problem ticket open. Maybe this will get resolved from one side or the other (but I'm not counting on it).
I have not heard from Dmitry. I have spent some time with a WD tech and we got a successfule connection long enough to take a couple backups but (now that I'm no longer on the phone with him) it is failing again. But this at least has shown me my original assumptions about the failure were wrong.
I think AHTI is saving some information about the FTP from an earlier (bad) attempt to make the connection. It seems to think that I want to put backups in the root directory of my MyCloud server. And it still thinks this after I've removed any and all backups referencing the server. (There are no ftp connection registry records for WDMyCVloud - it's saved somewhere else.)
When listing possible backup destination it lists MyBookLive and WDMyCloud. If I pick MyBookLive it chooses the directory where I put backups. If I pick WDMyCloud, it picks the root directory. I think (but don't know) that this is the source of the problem.
Does anybody know how to completely remove all information from the "My FTP connections" list? I assume I can uninstall AHTI (incluing the Acronis AppData folder), then reinstall and start over from scratch with backup definition. But I'd rather not have to do that.
Patrick,
I have previously connected to my WD-Mycloud via FTP without issue as well. However, upon just trying, it was behaving the same way - was not allowing me to connect through Acronis or Windows. I was not getting prompted for any credentials and it would not prompt me for credentials with adding my username@ in the ftp link either. I logged into the MyCloud device and turned FTP off, then turned it back on, waited about 10 seconds and tried and it immediately prompted for credentials the first time I tried to connect in Windows and now connects in Acronis too - wondering if yours is behaving the same way. If that doesn't help...
FTP and SMB credentials are stored in the regsitry and can be safely removed and once removed, will trigger new credentials be entered. Check out the KB article: https://kb.acronis.com/node/58004/
Also, grab the schedulemanager and see what additional old/ghost schedules may still be present and you can delete any that look odd, or run taskzap to delete them all and start with a fresh schedule
You may want to check Windows Credential Manager as well to see if there is an older FTP credential stored.
Once those are cleared out, start with a fresh/new backup job and during the creation, pick the source and destination and enter credentials as needed. Instead of navigating through the Acronis explorer, you can type the full UNC path into the top line and press enter - use the entire path you want the backup to go to before pressing enter.
Select destination >>> Browse >>>> top field "back up to": \\ftp://
Hope that gets you on the right track again.
Patrick,
I have previously connected to my WD-Mycloud via FTP without issue as well. However, upon just trying, it was behaving the same way - was not allowing me to connect through Acronis or Windows. I was not getting prompted for any credentials and it would not prompt me for credentials with adding my username@ in the ftp link either. I logged into the MyCloud device and turned FTP off, then turned it back on, waited about 10 seconds and tried and it immediately prompted for credentials the first time I tried to connect in Windows and now connects in Acronis too - wondering if yours is behaving the same way. If that doesn't help...
FTP and SMB credentials are stored in the regsitry and can be safely removed and once removed, will trigger new credentials be entered. Check out the KB article: https://kb.acronis.com/node/58004/
Also, grab the schedulemanager and see what additional old/ghost schedules may still be present and you can delete any that look odd, or run taskzap to delete them all and start with a fresh schedule
You may want to check Windows Credential Manager as well to see if there is an older FTP credential stored.
Once those are cleared out, start with a fresh/new backup job and during the creation, pick the source and destination and enter credentials as needed. Instead of navigating through the Acronis explorer, you can type the full UNC path into the top line and press enter - use the entire path you want the backup to go to before pressing enter.
Select destination >>> Browse >>>> top field "back up to": \\ftp://
Hope that gets you on the right track again.
I think that may be what the WD tech and I did to get it working, but no luck now: "Connection failed". Interestingly, Netstat shows that the FTP connection stays active when that happens. I have to completely exit the creation procedure for the FTP connection to be broken. The FTP connection is established, but not to TI's satisfaction.
I just took a WireShark trace while trying your idea. Even though I specified a URL of ftp://wdmycloud:21/Private/Test/, TI still just checked for root. In a trace I took of today's successful backup, it checked for the entire path, not root. Grrrrr.
I'm having hit and miss FTP with even Windows now. However, seems to be working best if I disable ftp on the mycloud to clear connections. I then go into the registry and delete Acronis FTP saved info. I then launch acronis and select the source as the FTP with the full path
I'm prompted for credentials and input them (just using the username and not the device/username). Takes a couple of seconds but connects to the root and then let's me navigate the shares. I pick the share and save and run teh backup and it works. Seems to work after that just fine. It even let's me connect in Acronis and with a second connection in Windows explorer at the same time (something I can't do with SMB shares).
At one point in Windows, it kept telling me credentials were wrong. I went back and put ftp://username@192.168.100 and then it prompted for credentials in Windows again.
So, can you turn off FTP on the NAS, clearn the FTP saved credentials in the registry, reboot for good measure, turn on FTP on the NAS and try to connect to the FTP share in Acronis before ever trying directly in Windows File Explorer?
Which command are you using with netstat to see if the connection is still open (netstat -an just keeps going so I was hoping there was a more specific command to target port 21 or FTP connections specifically?)
I'm having hit and miss FTP with even Windows now. However, seems to be working best if I disable ftp on the mycloud to clear connections. I then go into the registry and delete Acronis FTP saved info. I then launch acronis and select the source as the FTP with the full path
I tried disabling and reenabling FTP. It didn't help. The Mycloud registry entries are gone, but Acronis still has some information somewhere else. It still knows about MyCloud in the data displayed in the "My FTP connections" list. I haven't found how to get rid of that.
I'm prompted for credentials and input them (just using the username and not the device/username). Takes a couple of seconds but connects to the root and then let's me navigate the shares. I pick the share and save and run teh backup and it works. Seems to work after that just fine. It even let's me connect in Acronis and with a second connection in Windows explorer at the same time (something I can't do with SMB shares).
That's the way it works for me with MyBookLive. And that's the way it briefly worked twice yesterday with MyCloud ... but not any more.
At one point in Windows, it kept telling me credentials were wrong. I went back and put ftp://username@192.168.100 and then it prompted for credentials in Windows again.
Interesting. I kow Windows saves the credentials for Smb connections there, but I didn't think it even saw FTP credentials. In any case, it hasn't saved the FTP credentials for my MyBookLive connections (which work) or my MyCloud connections (which usually don't work).
So, can you turn off FTP on the NAS, clearn the FTP saved credentials in the registry, reboot for good measure, turn on FTP on the NAS and try to connect to the FTP share in Acronis before ever trying directly in Windows File Explorer?
No change. It doesn't work.
Which command are you using with netstat to see if the connection is still open (netstat -an just keeps going so I was hoping there was a more specific command to target port 21 or FTP connections specifically?)
I just did a netstat with no parms. Yes, there are sometimes lots of connections but I have few with MyCloud so I just do an eye-ball scan. I think I used to know other commands (on a on-indows platform) that were more specific, but I've forgotten them.
I' going to have to put this problem aside for a few days. The my next step will be to delete Acronis and all associated files from a "test" PC I have, reinstall Acronis, and see if I can make the connection. If that doesn't work I'm going to give up. I'll create the backups to a local drive and use post-backup commands to kick off an FTP outside of Acronis - using FileZilla or WinSCP.
For what it's worth, I just confirmed that this problem was not resolved by upgrading to ATI 2017. I did not, however, do a clean install so I really should use the Cleanup Utility and reinstall ATI 2017 before further comment.
As the month's delay indicates, I have moved this project to the back burner. I'm currently taking FTP backups to a MyBookLive NAS and then doing a Safepoint backup to the MyCloud NAS.
I have spent many, many hours trying to get this GD program to work as it is supposed to, and I am incensed that Acronis doesn't do anything to fix it. Obviously, after going on for so many years, this is a programming bug that these people don't want to address. It seems they want to spend more money to buy off the appraisers (PC Magazine, et al), than to actually produce a program that works correctly. Give me my GD money back you scoundrels!!!!
James, welcome to these user forums. We are just users the same as you, so if you are serious about wanting your money refunded, you will need to contact Acronis Support directly - click on the Support link at the top of any of the forum pages, then look for Contact Support lower down the new page on the right side.
I have spent many, many hours trying to get this GD program to work as it is supposed to, and I am incensed that Acronis doesn't do anything to fix it. Obviously, after going on for so many years, this is a programming bug that these people don't want to address. It seems they want to spend more money to buy off the appraisers (PC Magazine, et al), than to actually produce a program that works correctly. Give me my GD money back you scoundrels!!!!
Note that the problem I was grumbling about in this thread relates specifically and only to FTP failures between Acronis True Image and an FTP server on a Western Digital MyClousd (gen 2) NAS. It's not clear to me exactly what problem you are running into. If it does not involve a problem using FTP in Acronis True Image and/or does not involve my configuration, you should report your problem to Acronis. They can't fix bugs they don't know about.
Acronis support is looking at diagnostic data they had me collect. (I don't believe they have looked at the packet trace I gave them, but they may eventually get around to it. I hope they do because I think it clearly documents an Acronis bug.) They don't seem to be working on this problem very fast, but to be fair to the Acronis support team, a bug in their FTP support that appears only with one type of FTP server has to be very low priority.
Since I last updated this thread I have sort of given up. I bought a new Western Digital MyBookLive NAS - because Acronis successfully talks with its FTP server - and now have the configuration I was trying to set up months ago. The MyCloud is considered an upgrade to the MyBookLive, and is certainly less expensive for the same amount of disk space, but sometimes it's worth paying a bit more for something that works correctly.
Details of the failure:
The MyCloud FTP server has a peculiarity (which might be a bug) that confuses ATI. The server reports that it supports the "new" directory displaying FTP command "MLST". When given the command "MLST /" - display the contents of the root directory - the MyCloud FTP server replies "550 Can't check for file existence" - a security kind of rejection. However, if given the old "DIR /" command the server displays the contents of the root directory (or as much of the directory as the user is allowed to see).
Since the server has said it supports "MLST', ATI issues "MSLT /" and the server returns the error message. At that point ATI simply stops talking with the server. It doesn't break the connection; it just stops communicating. (Bug!)
So a bug (or serious peculiarity) in the MyCloud FTP server and a bug in the Acronis FTP client interact to cause a failure.
Update: It's very possible that I've misunderstood the purpose of the FTP MLST command - it may not be the equivalent of a DIR command. But is certainly wrong that Acronis stops communicating on the connection (but leaves it open) when getting the 550 reply to MLST.
I have spent many, many hours trying to get this GD program to work as it is supposed to, and I am incensed that Acronis doesn't do anything to fix it. Obviously, after going on for so many years, this is a programming bug that these people don't want to address. It seems they want to spend more money to buy off the appraisers (PC Magazine, et al), than to actually produce a program that works correctly. Give me my GD money back you scoundrels!!!!
Ditto to Steve's reply to James - please contact technical support if you have a licensing issue or customer complaint. There's nothing we can do here in the user forum to get you your money back. If you have recently purchased, I doubt there will be little trouble in obtraining a refund. If you purchased 2016 some months back, you'll have to work it out with Acronis, but the policy is 30-days no questions asked for all purchases. Beyond 30 days, it's really up to Acronis to decide if they want to offer a refund, or perhaps an upgrade instead - or, nothign at all. Do work with them and hopefully there's an amicable resolution.
That said, if yoiu are having NAS issues in 2016...
58004: Acronis True Image 2016: Troubleshooting Issues Related to NAS Credentials
57992: Acronis True Image: NAS Is Not Detected
Details of the failure:
The MyCloud FTP server has a peculiarity (which might be a bug) that confuses ATI. The server reports that it supports the "new" directory displaying FTP command "MLST". When given the command "MLST /" - display the contents of the root directory - the MyCloud FTP server replies "550 Can't check for file existence" - a security kind of rejection. ...
Since the server has said it supports "MLST', ATI issues "MSLT /" and the server returns the error message. At that point ATI simply stops talking with the server. It doesn't break the connection; it just stops communicating. (Bug!)
So a bug (or serious peculiarity) in the MyCloud FTP server and a bug in the Acronis FTP client interact to cause a failure.
I got some information from Acronis support:
I would like to inform you that we were going through the reports and found that it is a known issue with Acronis True Image 2017. This issue has already been reported to the developers and it will be mostly fixed in upcoming builds.
That "mostly fixed in upcoming builds" is an interesting statement. :-)