ISP has 'UPGRADED' hosting - FTP no longer works

[Vegit8]

My ISP (123) recently moved their hosting and 'upgraded' their offering.
After a bit of 'to-ing and fro-ing' with their support I have now figured out the FTP connection and can get files to the correct folder.

I am now having problems with being able to upload viable files, there seems to be an issue with renaming the temp files.

Looking in the (attached) FTP log file I can see a some files are pathed with a double // - like this -> public_html/weather//realtimegauges.txt

I also get the feeling that folder/file permissions are preventing the renaming.
The folder where the files are uploaded to has 0755 permissions, new files are listed as 0644.
I would have thought that new files would inherit the folder permissions.

I am using the admin ID as the FTP user in the FTP configuration of MX

Perhaps someone can give me an idea as to whether this is an MX issue or my host. Thankfully support is good, so I just need to 'say the right words' to get a fix.

site address www.geoffwebber.co.uk/weather today.htm was uploaded manually by me as a test.

I am running the latest version of MX

[water01]

I think you have a "/" at the end of your Remote FTP Directory in Internet Settings / Web/FTP Site.

Remove that and the extra / should disappear.

[Vegit8]

Hi.
Thanks for the suggestion - but i dont have a trailing slash (public_html/weather).
In any case paths for other files (:\CumulusMX\web\realtimegauges.txttmp to weather/realtimegauges.txt) seems to be OK

Cheers

[freddie]

I also get the feeling that folder/file permissions are preventing the renaming.
The folder where the files are uploaded to has 0755 permissions, new files are listed as 0644.
I would have thought that new files would inherit the folder permissions.

There's nothing wrong with those permissions - 0644 is what you need for your user to read/write the file and anybody else to just read. Having 0755 permissions on a file just sets the execute bit - and there's no need to execute your data files (not that you could anyway).

One thing you could check is that the owner of the files is correct.

It looks as if maybe MX could be running into problems with opening connections to transfer files (distinct from actually logging on). It might be useful to restart MX in debug mode, run it for a while, and attach the log files from MXdiags folder to a reply to this thread.

[Vegit8]

MX Diags - as requested

[ConligWX]

try changing the path in the Remote FTP Directory

Code: Select all

public_html/weather/

to

Code: Select all

/public_html/weather

as water01 initially stated.

[Vegit8]

Ok ...
So I have added the leading / as suggested and checked that there is no trailing / as also suggested.

Neither has made any difference.

Here is an extract from the latest ftp log with those changes applied.
Still have double slashes, and still no files being uploaded.

Code: Select all

2021-02-02 15:14:29.332 Realtime[3]: Uploading - realtime.txt

2021-02-02 15:14:29.333 FTP[3]: Uploading realtime.txt to /public_html/weather//realtime.txttmp

# OpenWrite("/public_html/weather//realtime.txttmp", Binary)
Command:  TYPE I
Response: 200 TYPE is now 8-bit binary

# GetFileSize("/public_html/weather//realtime.txttmp")
Command:  SIZE /public_html/weather/realtime.txttmp
Response: 213 0

# OpenPassiveDataStream(AutoPassive, "STOR /public_html/weather/realtime.txttmp", 0)
Command:  EPSV
Response: 229 Extended Passive mode OK (|||50779|)
Status:   Connecting to 92.204.223.27:50779
Command:  STOR /public_html/weather/realtime.txttmp
Response: 150 Accepted data connection
Status:   FTPS Authentication Successful
Status:   Time to activate encryption: 0h 0m 0s.  Total Seconds: 0.1219414.
2021-02-02 15:14:29.732 FTP[3]: Uploaded realtime.txt
Status:   Disposing FtpSocketStream...
Status:   Disposing FtpSocketStream...
2021-02-02 15:14:29.736 FTP[3]: Renaming /public_html/weather//realtime.txttmp to /public_html/weather//realtime.txt

# Rename("/public_html/weather//realtime.txttmp", "/public_html/weather//realtime.txt")
Command:  RNFR /public_html/weather/realtime.txttmp
2021-02-02 15:14:29.737 FTP[3]: Error renaming /public_html/weather//realtime.txttmp to /public_html/weather//realtime.txt : 

[HansR]

Is 'Delete before upload' checked? If not you might try that one, I think you then could even skip the renaming.
I am not a 100% sure but I think it should implicitly delete the old realtime.txt before renaming. Normally if the files exists already, you can't rename.

[ConligWX]

when you changed the setting, and saved it, you might require a restart of cumulusmx. just a guess.

[Vegit8]

OK ...
So I adopted Hans R's suggestion, and remopved the rename and added the delete commands to the FTP setup.

I now get realtime.txt and index.htm but both are 0 byte files...

Latest FTP log and MXDiags files attached

[HansR]

Yes, hmmm...

Some remarks:

1. the realtime.txt and index.htm seem to be copied correctly (can't explain the zero size though, see below)
2. Apparently e.g. today.htm does not exist or is not owned so it can't be deleted and then when trying to upload it says Object reference not set. To me that seems as if the required FTP object has been removed because of the deletion error.
3. Your gauges-ss.htm does not have the public-html in its path so it will fail anyway (but otherwise probably would have had similar errors).

The errors are repetitive, because of the object error it could be an error handling issue, I think Mark should have a look at it.
Could you check whether the files (like moon.jpg, today.htm or sunhours.json do exist on the remote site?
And if they do exist, what is the ownership/properties?

If they don't exist can you make them through e.g. WinSCP (or similar) can you tell which user has the directory and which has the files?
(yes I know you said the today.htm was copied manually so what is the owner of that file and is that the same owner as the user by which you log in from Cumulus?)

Boring questions maybe, but there must be something wrong with the user/properties setting. It is unlikely it is the software because that is working correctly in too many instances.

Wrt the zero size I can tell you I had the same problem with my provider when I switched to the FTP library used by CMX for my own software. I could never find the cause but I had to switch provider(!) and then it worked. So it may be an FTP dialect which is not working. I never found out the real cause.

[Vegit8]

Hans
Thank you for the detailed response - I have checked your remarks and here are my findings

Code: Select all

Apparently e.g. today.htm does not exist or is not owned so it can't be deleted and then when trying to upload it says Object reference not set. To me that seems as if the required FTP object has been removed because of the deletion error.

today.htm exists on my site it is an old file that I FTP'd manually - it is not zero btes in size.

Code: Select all

Your gauges-ss.htm does not have the public-html in its path so it will fail anyway (but otherwise probably would have had similar errors).

Quite so - I had forgotten that the pathings for these files existed elsewhere.
I have updated and restarted MX.

Code: Select all

Could you check whether the files (like moon.jpg, today.htm or sunhours.json do exist on the remote site?
And if they do exist, what is the ownership/properties?

These files exist - they are old ones that were ported over when the whole site was migrated to the new hosting platform.

Permissions / Ownership
All files (new or pre existing all have the same owner and group ID's - the credentials I am using are the admin set for this site as supplied by the host.
Prexisting files have 0666 for permissions (read / write all)
New files (realtime.txt) has 0644 (read / write owner - read everyone else)

As you say I think this may well need Mark to have a look - and ultimately I may need to move Host, as everything has worked fine for many years, and now it just doesnt.

[HansR]

Ok. Thank you.
You are not saying the user/group of the pre-existing files are the same as the admin user. Are they?
If they are not the same, could you simply remove those prexisting files (they are not useful anyway) and see what happens?

[ConligWX]

Sounds like a permission this then on the ftp account.

0 bytes means you have creation rights to create the file, but thats about it.

[Vegit8]

You are not saying the user/group of the pre-existing files are the same as the admin user. Are they?
If they are not the same, could you simply remove those prexisting files (they are not useful anyway) and see what happens?

Hans, all files have the same ID - as I am connecting as admin then all pre existing files also are 'admin'

Sounds like a permission this then on the ftp account.

0 bytes means you have creation rights to create the file, but thats about it.

According to the FTP permissions all files are Read / Write - which I assume includes delete