Blog

This is a little journey of fun that I wanted to record.  If you happen to own a Webfusion shared account and you navigate to the Webfusion Support Site, selecting the Hosting → Webspace & Access access path, then you will find the page How can I upload my website using FTP? which describes how to set up an FTP client (in this case Filezilla) to access your web space through FTP using your domain (which in my case is ftp.ellisons.org.uk).  The only problem with this for me is that method just doesn’t work.  In case you can’t be bothered with this whole exposition, then I’ll give you the short version upfront: don’t use “ftp.yourdomainname.co.uk” as the article tells you to; use the correct home server (in my case ftp2.myserverworld.net ) and everything works fine.

I have opened a couple of support calls on this to no avail.  Here was my first incident (Ticket: 100303-000398):

I can't get in using FTP with Filezilla or basis FTP. I get the same error. Here is a console dump of an FTP attempt:
terry@ellison6:~$ ftp ftp.ellisons.org.uk
Connected to ftp.myserverworld.net.
220-Microsoft FTP Service
220 ftp server 29
Name (ftp.ellisons.org.uk:terry): XXXXXXXXXXXXX@ellisons.org.uk
331 Password required for XXXXXXXXXXXXX@ellisons.org.uk.
Password: XXXXXXXXXXXXX  <<I paste the password from a copy that I used to log on here>>
530 User cannot log in, home directory inaccessible.
Login failed.
Remote system type is Windows_NT.
I need FTP access as some thing can't be done from the web browser interface (such as modify the hidden file .htaccess)

The first response was “We have logged into your webspace with the ftp details on file and have managed to view the root folder and also logs folder without any loss of connection or errors.  The ftp client used is also filezilla.  Unfortunately we have not been able to replicate your issue.“  So I then sent them a scripted version which repeats the problem, and had a couple of more attempts and “does not compute” style answers uploaded the script + its output.  In this exchange I pointed out if I typed out a deliberately incorrect password, then I didn’t get the “home directory inaccessible” error.  Eventually, I missed the 3 day response window after which the case is automatically closed.

My first attempt at a workaround was to set up a FTP second account through the WF MyserverWorld control panel.  This gave even more bizarre results: The new account FTP worked to ftp.ellisons.org.uk for read-only access, but not write access.  So I then set up a subdirectory with world:read+write+execute, and the files could be created in this case but they had root UIC ownership (Tickets: 100304-000013 and 100316-000526).  At least suPHP is configured to prevent use of such files.  The support team didn’t seem bothered by this: “This is to confirm that this ticket is now passed over to Sebastian to investigate and process your support query.” (and at the same time the case was closed.)  The only way that I could show that this could be exploitable would be to find such an exploit, and this is a step too far as I am concerned.  Anyway, here are three workarounds that I’ve found:

• Connect to ftp2.myserverworld.net.  I tried this after pinging my FTP domain and decided to see if this was a domain virtualisation problem with their FTP package.  This server in the myserverworld.net domain is the reverse DNS name for the FTP server given in my “Getting Started” email.  Everything works fine when I use this.  This FTP session homes on my public_html directory (so it doesn’t give me access to my logfiles directory).  I suspect that the support team connect through this, which is why they couldn’t replicate my error.
• Use the WF MyserverWorld control panel to navigate to the webftp window.  (You need to go via MyserverWorld to authenticate and set up a session context.) This gives access to both the public_html and logfiles directories.  I also see that this now lists off hidden files such as .htacess.
• Use my own PHP script. I do this because I like to do my bulk transfer using bz2 compressed tarballs and to expand them locally at the destination.  Another alternative would be to use rsync but that requires some configuration, and both of these options are really the subject of another post.

It’s now 8 moths since I first logged these issues.  As of this morning, I retried the cases that I logged and the failure modes are still there.  I am an advanced user who can develop workarounds, but these would defeat most users.  This is an example of how a service can be let down by poor support, and it’s no surprise to me therefore that Webfusion seems to get consistently terrible user ratings.  This is a shame because in my experience, it is otherwise a well-priced and effective service.