# Resolving ‘curlftpfs’ – Error 530 …I/O Error.

One of the ideas which I recently saw another enthusiastic Linux user comment about was, that the program “Bluefish”, which can be installed from Linux package-managers, is almost an ideal program for Web-design, and one of the reasons given was the fact that additionally, under Linux, it’s possible to mount a remote FTP-server’s directory, to a local mount-point, and then, to edit the HTML, CSS and PHP Files directly within this mount-point. While I like enthusiasm for a good thing, I would prefer not to lead my readers into a situation where they could run into error messages, and then become frustrated, because they might not be able to resolve those. Instead, I’d prefer to have run into some error messages myself, found a solution, and then explain to the community, what worked for me.

For starters, even though I do some minimal Web-design, my way of doing it is, to maintain a set of folders within my home directory, which stays synced between my computers, but then, to use “FileZilla” to upload changes I made to those folders’ files, to an FTPS-server, with point-and-click methods. FileZilla can also be installed from most Linux package managers, has a GUI, and supports secure connections to the FTP-server. If the reader is paying attention, he or she will notice that by implication, I have an FTP-server running on the PC that acts as my Web-server, that I force the exchange of passwords to be encrypted, and that my FTP-server and -client reside side-by-side on computers in the same room, on my private LAN.

The reader may infer that I’m not the most trusting person.

In this context, Linux users differentiate between two methods of file-sharing:

• File-Sharing over SSH, which is sometimes referred to as ‘sftp’. If this is set up, then the local mounting of the remote FS becomes dead-simple, Or
• FTP File-Sharing over TLS, which is referred to differently as ‘ftps’. My assumption for this posting is, that ‘ftps’ is set up, but that ‘sftp’, or, ‘ssh’ is not, for the account in question…

But, just to verify whether the option can be forced to work, that the actual FTP-server’s directories can be mounted locally, and then, theoretically, also edited in-place, I next discovered that virtually the only solution available is a package called ‘curlftpfs‘, which performs a FUSE-mount. Lately, I’ve begun to like FUSE-mounts, especially without any of the mount options that would require root. But what I found next was, that ‘curlftpfs’ was particularly temperamental. Whatever the client-side mount doesn’t like about the server-side configuration, results in a short error message, and perhaps, a frustrated Web-author.

And so, I’m happy to share what it was, that made the error message go away in my situation. The first thing that the reader would need to visualize is, how the system directories are set up, using ‘vsftpd’, in this case for the user ‘www-data’, which owns all the Web-content, and, exposing Port 21 to the LAN, but not even to the WAN. This is the root of any static HTML I might want to host:


Directory               Owner
------------            --------
/var                    root
+-www                 root
+-html              www-data



While this detail may strike the reader as irrelevant, in fact it’s not, as I found out. That would be, because the Home Directory of the user ‘www-data‘ was set up, by me, several years ago, as being ‘/var/www‘, not, ‘/var/www/html‘. What this means is that, unless some directive was set up on the client-side, to navigate to sub-directory ‘html‘ directly when logging in, from wherever this FTP user’s home directory was, the simple diagram which I just wrote above, would cause the Error 530 Message.

Further, in my configuration file ‘/etc/vsftpd.conf‘, I have the following lines set:


userlist_enable=YES
userlist_file=/etc/vsftpd.userlist
userlist_deny=NO



What this means is that, in the additional file ‘/etc/vsftpd.userlist‘, I have the list of users, who are allowed to use FTP. And, ‘www-data‘ is the only user in the list.

I should also mention that the user-name ‘www-data‘ has its login shell set to ‘/bin/false‘, just to reduce the risk further, of any sort of hacking.

But there was a simultaneous problem causing the same error message: When the ‘curlftpfs’ command is given, with the ‘tlsv1′ option, at least on the Debian 9 / Stretch client, this just causes the authentication error, regardless of how sure the user has been, that his username and password were provided correctly. What’s peculiar about that is the fact that, on my FTP-server, the file ‘/etc/vsftpd.conf‘ does also have the following lines set:


ssl_enable=YES
ssl_tlsv1=YES



Further, setting ‘Explicit TLS handshake’ in FileZilla, never caused any sort of error messages. What I take this to mean is that either:

• ‘curlftpfs’ tries to set a version of TLS which would be higher than 1.0, Or
• Trying to set this option both on the client and server, causes the obscure error…
• (See footnote :1 at the bottom of this posting, for the correct explanation.)

I should also note, that ‘the correct way’ to get this mount to work would be, that the user set up the file ‘~/.netrc’, that being, a file in his home directory, on the client computer, that stores his username and password in plain-text form. It’s important to give the command:


$chmod go-r ~/.netrc   I.e., access to this file should be limited to reading, and perhaps writing, by the user in question. If the user enters his password on the command-line, then it will also go into the command-history of his shell interpreter, and additionally, be visible in the processes list. This is one possible, correct ‘.netrc’ File, for use with ‘curlftpfs':  machine dirkmittler.homeip.net login www-data password <my-password>   What I eventually found out was, that ‘curlftpfs’ does in fact read and use this file correctly. But, once I got my FTPS-mount to succeed, I also deleted this file, and continued my experiment with the following command-line: $ curlftpfs -o ssl,no_verify_peer,user=www-data ftp://dirkmittler.homeip.net/html ~/mnt



What the ‘user=www-data‘ option does is, to cause the command to ignore the ‘.netrc’ File, and to prompt the user to type in his password (invisibly) by hand. I found that using this feature eventually also works. And, at the end of the (remote computer’s) host-name, in my case, the characters ‘/htmlare important, for the reason I gave above.

The following command also works:


$curlftpfs -o ssl,cacert=/home/dirk/vsftpd.pem,user=www-data ftp://dirkmittler.homeip.net/html ~/mnt   The last command assumes that the file ‘~/vsftpd.pem‘ contains the public certificate that my self-signed FTP-server uses, and causes the mount command to check the actual server’s public key for equality. Conclusion: Although this mode of operation can be forced to work, I wouldn’t prefer it as my main way of uploading files, because it’s just too rickety. (:2) I’ll just go back to using FileZilla. (Updated 9/28/2020, 22h45… ) (As of 9/27/2020, 11h55: ) 1:) The reason why the command-line option ‘tlsv1‘ gave the ‘Error 530′ Message was, the expectation by the programmer that the user also give the option ‘ssl‘. In short, when the option ‘ssl‘ is not given in the mount command, this offers to authenticate the client in plaintext, which the server refuses, but which the mount command just reports back to the user, as if the user had given false credentials. Hence, the following command-line works perfectly: $ curlftpfs -o ssl,tlsv1,no_verify_peer,user=www-data ftp://dirkmittler.homeip.net/html ~/mnt



(Update 9/27/2020, 14h40: )

2:)

I thought I would give this a try on my laptop as well. The computer on which I do most of my computing, is an octa-core Debian 9 / Stretch machine, which could already be considered outdated in terms of software, but which is still quite solid in terms of hardware. Its name is ‘Phosphene’. I also have a quad-core Debian 8 / Jessie laptop, which I name ‘Klystron’, for which a similar description would seem fit.

The laptop uses WiFi to connect to my LAN while the tower computer I named ‘Phosphene’ uses a Gigabit Ethernet jack.

When trying this from my laptop (to the server in the same room, named ‘Phoenix’), I ran in to the problem that, even as I was trying to list the mounted directory, I obtained a famous I/O Error instead of a directory listing. But, if I gave the ‘ls’ command a second time, I obtained an adequate directory listing.

I could go deeply into theories as to why, exactly, the laptop seems less reliable in this mode than my tower computer ‘Phosphene’ does. I even custom-compiled the ‘curlftpfs’ program on the laptop, to make sure I got the latest version. But the behaviour was the same. I’d say that the following stats pretty much quiet my remaining curiosity into the question:


dirk@Phosphene:~$curlftpfs -V curlftpfs 0.9.2 libcurl/7.52.1 fuse/2.9 dirk@Phosphene:~$

dirk@Klystron:~$curlftpfs -V curlftpfs 0.9.2 libcurl/7.38.0 fuse/2.9 dirk@Klystron:~$



What this tells me is, that the version of ‘curlftpfs’ has not changed in recent years, and, that the ‘fuse’ libraries likewise, have not changed much. Offhand, I would conclude that the older version of ‘libcurl’ fails to provide a network connection to the server, that is stable enough to be basing a virtual file-system on. In networking, there exist hardware-related issues, that can be managed better at the application level, through an application reconnecting if the connection was dropped, etc., which are just not solved as easily, within a network FS mount.

Additionally, it’s very possible that the FTP protocol is even less suited to be mounted as a virtual FS, than an SSH file-share. It’s possible that ‘vsftpd’ is a particularly laxidasical FTP-server, in terms of dropping packets and dropping clients… In such a case, FileZilla just reconnects.

Now, I suppose that I could further pursue the question of whether that laptop has kernel issues. But if it had kernel issues that lead to failures within FUSE, then I’d also expect other types of FUSE-mounts to be failing on it, left, right and centre. But all the other FUSE-mounts on the laptop named ‘Klystron’ have struck me as stable throughout the ages. And, it’s not as if the FUSE version itself was different…

(Update 9/28/2020, 22h45: )

I have discovered an important ‘feature’ of ‘curlftpfs’, which needs to be known by its users, for full benefit. This client program needs to establish many simultaneous sessions on the same server, for the same mount. For that reason, if the FTP-server happens to be ‘vsftpd’, then its configuration file needs to have the following parameter either set as below or left at its default:


max_per_ip=0



Dirk