Support

Have I read the related troubleshooter articles above before posting (which pages?)? Yes
Have I searched the forum before posting? Yes!
Have I read the documentation before posting (which pages?)? Walkthrough, options, overview
Joomla! version: 1.5.23 or 1.5.24
PHP version: 5.3.1
MySQL version: (unknown)
Host: (optional, but it helps us help you)
Akeeba Backup version: varies

Description of my issue:

I have successfully gotten Remote CLI up and running (a painful transition for me from the old Remote Control!) ... but there are a couple of sites that are having problems.

The backup and download on those sites APPEARS to be successful -- no errors in Remote CLI ... but the file it "downloads" to my local machine is 0kb -- it's clearly not completing the download.

In the site's back end in "Administer Backup Files" the Remote CLI backup is listed as successful, but the .jpa file is there -- not downloaded and not deleted as the script calls for.

Here's an example of the command in my .bat file:

php remote.phar --action=backup --host=http://domain.com --secret=secretword --profile=1 --download --dlmode=curl

--dlpath="c:\jobs\backups\domain" --dlurl="ftp://user:[email protected]/public_html/administrator/components/com_akeeba/backup" --delete

What could this be? Because it's creating the .jpa filename in the local directory, I know it's finding the directory and starting the download ... but it's not completing it for some reason.

Laurie

I didn't know that. So it must be the line about the remote directory that has the problem. I am triple-checking everything again. I was using an output directory outside the root (per Akeeba's instructions for best security), and when that didn't work with Remote CLI, I thought maybe I needed to stay inside the root, so I changed it to the default output directory. The settings on that new directory are 755, which is the same as on other sites that do download successfully, so I don't think that's it ... I'll keep looking.

This has been such a long process getting converted to CLI -- I had to upgrade my version of PHP which led to a whole XAMPP upgrade, that led to other problems, I finally fixed those, then had to learn how to do batch files, etc. I still have several sites using older versions of SEF that I need to upgrade before I can even use CLI on them. Sigh. I know you had good reasons to drop the old Remote Control but that was so effortless to use, at least for me.

Thanks for helping me through it, I'll keep working on it.

Laurie

Thanks for this additional guidance -- I'm making progress! I fixed the error in one of the problem sites anyway -- turns out for this particular host I needed "domain.com" listed twice before /administrator etc. in the path -- but now I'm only getting a partial download (I think), and no delete on the server.

The file it downloads to my local machine is 44MB. When I look at the back-end of the site, it says the remote backup was successful but the size is 82MB and there's a "Part 00" file there on the server. Is this file too large to download so the FTP is timing out here or what does that mean?

AND I know the problem on my other troublesome site. It turns out it needed "@domain.com" added to the username for ftp -- but I don't know how to add that. The walkthrough says to use double quotes but the path is already in quotes ... what should the syntax be to make that work?

This is what I have (which doesn't work):

--dlurl="ftp://[email protected]:[email protected]/public_html/administrator/components/com_akeeba/backup"

So close!

A HA! That "pause" was important. I was testing the second site at the same time in a test script, and I think it was error-ing on that second site and therefore closing the window abruptly while the first file was still downloading. I would not have thought of that on my own, thanks for catching that. So that site is all set.

Now if there's a way around the "@" in the ftp username, I should be good to go. Whew!

Yikes, now I'm a beta tester! Yup, this one site is on a cruddy host. I tried the new remote script and it tells me this:

Error #103: Could not download (gives path) -- 67 : Access denied: 530

I'm positive (well, pretty positive) that the only gotcha in that site's download call is the @ in the username; I can connect and download with these settings in straight FTP.

I was wrong and I'm so sorry I wasted your time, I can't apologize enough, there was a mistake in the password I missed somehow. I ran the script again and it works like a charm. Both my problem sites are up and running with CLI. If I can just get through the SEF component upgrades on a couple other sites so that CLI will work on them too, I'll be in good shape.

Any reason not to use this unreleased version of CLI for all my sites ... or should I just use it for the one site with an @ in the username for now?

Thanks for all your help sorting through this today,

Laurie