View Full Version : FTP error on move/copy between galleries
bobbeela
3rd of March 2004 (Wed), 14:51
I get the following error message when I move or copy a picture from one galery to another.
msg 621 | ftp
MICROTHUMB DOWNLOAD ERROR.
to: ../ftp_temp/USA1997-03-32.jpg
from: USA1997-03-32.jpg'.
Reason: ftp_get() expects parameter 1 to be resource, null given
[Wed Mar 3rd, 2004 21:42:59]
Anybody got a clue?
Pekka
3rd of March 2004 (Wed), 17:37
Ftp connection lost or never achieved. Try using internal ftp so you'll get better and more verbal error messages. You can activate internal ftp in ftp server page.
bobbeela
4th of March 2004 (Thu), 11:15
The FTP tests fail and the message reads:
-----------------------------------
msg 3487 | internal ftp: ERROR: unable to connect to server (server not responding in 30 seconds). Exiting...
msg 3486 | internal ftp: 81.91.3.112 ftp.terkeurst.net
msg 3485 | internal ftp: EE terkeurst.net: FTP TEST PROCEDURE STARTED
msg 3484 | internal ftp: EE terkeurst.net
-----------------------------------
The system messages read:
-----------------------------------
msg 3495 | internal ftp
ERROR: unable to connect to server (server not responding in 30 seconds). Exiting...
[March 4th, 2004 06:15:41]
msg 3494 | internal ftp
81.91.3.112 ftp.terkeurst.net
[March 4th, 2004 06:15:41]
msg 3493 | internal ftp
EE PROGRAM SERVER: FTP TEST PROCEDURE STARTED
[March 4th, 2004 06:15:41]
msg 3492 | internal ftp
EE PROGRAM SERVER
---------------------------------
I've applied RC2-fix1. Doesn't matter whether you set the extra to 'default' or 'dual pasv' and the delay to 'off' or any other setting.
Pekka
4th of March 2004 (Thu), 13:35
Please PM me your editor location and login data (do not post them here!), I'll take a look - I have seen this problem once before and it is most likely be a server firewall issue, but I'd like to test couple of things to make sure.
Pekka
4th of March 2004 (Thu), 14:43
Thanks got the PM and got little more info on this error:
The real error message from ftp server is "Bad file descriptor" which seems to be a bug in Redhat 9's default ftp server and tcp wrappers. More info about this and one way how to fix it in http://www.linuxforum.com/forums/index.php?showtopic=2323
Basically the error seems to mean that ftp server bugs when connection is initiated from localhost (the php process). I can connect ok from here but not from server.
You cannot do anything about yourself, unless you are system adminstrator. To resolve this error you should contact your server support and hand them this info. Let the support staff in to your EE input folder for testing purposes. I have placed some new code there which prints the actual ftp error string on ftp test report window for them to verify it, e.g.
server: XXX.XXX.XXX.XXX
port: 21
errno: 9
errstr: Bad file descriptor
timeout: 60
Let me know what happens.
D-Hosting
5th of March 2004 (Fri), 03:56
I am the engineer of the hoster where bobbeela hosted his site. We don't use vsftp but proftpd. I can't find a setting tcp_wrappers in the config files. I will look further, but if you have a remark about proftp and this problem, please reply! I will check this topic.
Pekka
5th of March 2004 (Fri), 09:38
I am the engineer of the hoster where bobbeela hosted his site. We don't use vsftp but proftpd. I can't find a setting tcp_wrappers in the config files. I will look further, but if you have a remark about proftp and this problem, please reply! I will check this topic.
Thanks for checking it out.
I'm not a Linux guru so my knowledge of this problem is restricted to what I find on net.
If you can access bobbeela's EE editor you can see that connect error reported BY ftp server is "error 9", and it comes asap when a tcp socket connection to ftp server is attempted from localhost (same with PHP ftp module, only the error message comes slower because it has different internal timeout system) . Perhaps ftp server logs reveal something about this error, or ProFtpD manual?
Could it be a firewall setting problem? Because with exactly same code and same settings I can get in the server from Finland and all tests are 100% ok :shock:
D-Hosting
8th of March 2004 (Mon), 04:39
I tried it with the firewall on and off. No changes. So I don't think so.
bobbeela
8th of March 2004 (Mon), 14:41
I've searched the proFTD manual and the only thing I could find on setting anonymous access is in http://www.devshed.com/index2.php?option=content&task=view&id=61&pop=1&hi de_ads=1&page=0&hide_js=1.
---------
Typically, the "ftp" user on the system is configured without a password - which makes it impossible for any user to log in at this time. Therefore, the server needs to be configured to recognize the "ftp" and "anonymous" users, and grant them access to the appropriate public area on the server.
Setting up an anonymous FTP server with proFTPD is simplicity itself - all you need to do is use the special <Anonymous>...</Anonymous> block, which contains configuration parameters for the operation of your FTP server.
In order to enable anonymous FTP, pop open your "proftpd.conf" file and add the following code block to it:
# set root directory for anonymous users to /home/ftp <Anonymous/home/ftp>
# set the user and group for the server process
User ftp
Group ftp
# alias "anonymous" login to "ftp"
UserAlias anonymous ftp
# restrict "anonymous" users from writing data
<Directory *>
<Limit WRITE>
DenyAll
</Limit>
</Directory>
</Anonymous>
Obviously, you should make sure that an entry exists for the user "ftp" in your system's password file, and that the directory "/home/ftp" exists before activating this configuration. Once you're done that, restart the server and try logging in again as an anonymous user.
$ ftp localhost
Connected to localhost (127.0.0.1).
220 ProFTPD 1.2.8 Server (ProFTPD) [olympus.melonfire.com] Name
(localhost:joe): ftp 331 Anonymous login ok, send your complete email
address as your password.
Password: *******
230 Anonymous access granted, restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
227 Entering Passive Mode (127,0,0,1,4,199).
150 Opening ASCII mode data connection for file list
drwxr-xr-x 3 ftp ftp 4096 Apr 28 06:45 pub
226 Transfer complete.
ftp> cd pub
250 CWD command successful.
ftp> ls
227 Entering Passive Mode (127,0,0,1,4,207).
150 Opening ASCII mode data connection for file list
-r-xr-xr-x 1 ftp ftp 8820072 Jul 15 2002 ar500enu.exe
226 Transfer complete.
ftp> get ar500enu.exe
local: ar500enu.exe remote: ar500enu.exe
227 Entering Passive Mode (127,0,0,1,4,209).
150 Opening BINARY mode data connection for ar500enu.exe (8820072
bytes) 226
Transfer complete. 8820072 bytes received in 2.05 secs (4.2e+03
Kbytes/sec)
ftp> put mbox
local: mbox remote: mbox
227 Entering Passive Mode (127,0,0,1,4,211).
550 mbox: Permission denied
ftp> cd /
250 CWD command successful.
ftp> cd ..
250 CWD command successful.
ftp> pwd
257 "/" is current directory.
ftp> bye
221 Goodbye.
As you can see, the system now gives you access and locates you in the "/home/ftp" directory. You have the ability to download existing files, though not upload new ones, and you can move around freely in the "/home/ftp" hierarchy, but not outside it. In other words, your basic anonymous FTP, good to go! By default, only users with real accounts on the system are allowed to upload files to the FTP server - and even they are limited to uploads in their home area. Anonymous users, as demonstrated on the previous page, do not have the ability to upload files to the server. This is a fairly reasonable safety precaution if your server is exposed to the public Internet, because you never know what malicious files might be uploaded to your server; however, if your FTP server is running on a closed network, you might want to enable file upload for anonymous users also (perhaps to enable file sharing between users at different locations).---------------
Could this be the problem on your (and mine) server?
Enno
Pekka
8th of March 2004 (Mon), 15:25
No, that is not it because the problem is not logging in or anything thereafter. Problem is that tcp ip socket on port 21 refuses localhost connection from your virtual server.
I've spend much time today searching for answers, and what I found is that the error #bad file descriptor) comes from socket interface (perhaps SOCKS from http://www.socks.permeo.com/AboutSOCKS/SOCKSOverview.asp ) and one way to get rid of it may be restarting socks server (or look for stray socket processes). Warm boot of server may also do it.
There are many similar error posts in socks server, like http://archive.socks.permeo.com/mail/socks5/msg00098.html and http://archive.socks.permeo.com/mail/socks5/msg00603.html
What also suggests that it is a socks configuration/hang problem (with localhost DNS of your virtual server) is that I can connect from outside of your machine without any problems. So it must be IP related and ftp server itself works ok.
I REALLY would like to see this found and solved - even if it is not directly an EE code problem I would like to offer a solution to all serverside problems, too.
D-Hosting
9th of March 2004 (Tue), 09:20
When I log in as Root and FTP to a existing domain on that server there is no problem logging in and transferring files. So the localloop (as from root) is not an issue.
We are, however, experiencing more difficulties with that server, such as not working of the PHP command fopen() to local and external sites.
It isn't the firewall, but what is it then? Will look at above links.
wkitty42
12th of March 2004 (Fri), 16:10
When I log in as Root and FTP to a existing domain on that server there is no problem logging in and transferring files. So the localloop (as from root) is not an issue.
We are, however, experiencing more difficulties with that server, such as not working of the PHP command fopen() to local and external sites.
It isn't the firewall, but what is it then? Will look at above links.
bad php install? box has been rooted?
bobbeela
18th of March 2004 (Thu), 04:08
We tested the site on another server. That solved the problem.
What the exact problem on the other server was, is not totally clear.
So we are moving the site to the other server.
Case closed.
Enno
Pekka
19th of March 2004 (Fri), 17:06
Ok, good. It would have been really nice to know what bad the server did eat but perhaps that reason was merely in category "s**t happens".
vBulletin® v3.6.12, Copyright ©2000-2012, Jelsoft Enterprises Ltd.