vsftpd: refusing to run with writable root inside chroot() - fix not working

Sorry, that problem wasn’t the web server, my networking went down hard, and I got so burned out trying to fix so many problems that I took a few days off, then upon returning I formatted the root partition and reinstalled the entire system from scratch. That fixed the broken networking, and you would think that solved the weird FTPd problem too, but it didn’t.

For now, just do the following and post the results.

You should choose to either use the YAST FTP server or not. Don’t mix the using YAST and manually editing files, particularly when setting up initially. Use the FTP Server module to set up a working configuration before starting to experiment.

Since I have now formatted the root partition, following those instructions are useless now, so let’s please start over. As to the choice between manual configuration or using Yast, I did not use Yast at all for configuring FTP, I habitually only do it manually.

Now, I decided firmly that I simply refuse to ever try using vsftpd again. Instead, I have installed proftpd, and again will not be using Yast to configure it either. (Moot point, since Yast cannot configure proftpd anyway.)

Now you would think after a format & new install, that the new FTP server would work. It isn’t. It’s running, but:

  1. When using ANY browser I get a white page and eventually times out.
  2. When using FTP in a terminal it connects, gives the usual info, responds to the help
    command, but on entering ls or dir it hangs without showing the directory contents, until it times out like this:

ftp> ls
200 PORT command successful
425 Unable to build data connection: Connection timed out

As you may recall, * I suffered *these same exact symptoms here before formatting the root partition, and it didn’t matter which ftp daemon I was using -it did it with all of them! This tells me that the problem is NOT in the daemon itself, or in the configuration, but it’s SOMEWHERE ELSE in the system, somewhere which is:

  1. not
    affected by formatting the root partition and newly installing the entire OS, and 1. not
    affected by changing to another ftp server, and 1. not
    affected by using different browsers. 1. Even using my tablet to connect results in the same symptoms.
  2. I even created a new user and tried from that account, with no difference. It affects all users on the system identically.

This weird problem started when I changed from opensuse 13.2 to installing a fresh Leap 42.2 after formatting the root partition. I had no such problems with 13.2, and since switching to 42.2 I’ve had a couple dozen weird problems, one of which is this problem which affects any and all FTP servers the same. This is what I need help fixing now.

It’s always problematic assuming things will work out of the box without any manual configuration on your part.

Recommend…
This is the ProFTPD page on configuring virtual Users
http://www.proftpd.org/docs/howto/VirtualUsers.html

Down a ways on the page, a general question about your options where virtual user accounts would be stored.
One of the suggested options is in a text file, if you wish to do so then you need to follow the steps outlined on the following page
http://www.proftpd.org/docs/howto/AuthFiles.html

You should find all necessary ProFTPD documentation installed on your machine in the same places I described the vsftpd documentaiton can be found.

Also, I recommend you do all your early testing using a command line FTP client because typically the ones I’ve used will automatically adjust to Active or PASV. A web browser may not automatically switch to what is available.

And, don’t forget to either drop your firewall or configure as necessary during your testing.

TSU

Before switching from 13.2 to 42.2 I was always using ProFTPD, and never had any difficulty with it. Never any configuration problem. I never had to configure any virtualuser anything, and never needed any fancy complicated authentication for anonymous users. For I don’t know how many years ProFTPD has always worked ‘right out of the box’ for me.

I have never used virtualusers, have no intention of using virtual users preferring just anonymous logins, and MAYBE my existing personal account, and don’t understand what virtualusers has to do with the problem I’m seeing. The same goes for all that talk of authentication. I never used these special things before, and don’t understand why they would suddenly be needed now for an anonymous login, or why not configuring them would cause the ls command to hang like this. I’m getting a migraine from reading all these files that don’t give a clue to the cause of the actual problem, or a fix for it.

Was something recently changed in ALL ftp servers (vsftpd, pure-ftpd, AND proftpd) to make all three of them require special complicated authentication techniques and virtualusers, just so people can log in as anonymous?

If all you want to do is support anonymoust logins, then I’d advise you to go back to vsftpd, configure using YAST because it’s the fastest way to configure properly and aside from anything you might need to uninstall you should be fully installed and working in less than 5 minutes.

I recommend vsftpd only because I just did a full test in my previous post. I didn’t test pureftpd which is the other FTP app supported by YAST but I’d expect that should work, too… For many years when vsftpd didn’t always work I always set up pureftpd without a problem.

TSU

Ok, you really aren’t getting what the symptoms are saying. It doesn’t matter WHICH ftp daemon I install, NONE OF THEM ARE WORKING RIGHT. EACH has the EXACT SAME PROBLEM with the ls command hanging it until it times out. To prove it I just DID remove proftpd and wasted my time installing vsftpd AGAIN with precisely the SAME EXACT PROBLEM, the only difference is that vsftpd also has an ADDITIONAL PROBLEM which the other two don’t have: vsftpd: refusing to run with writable root inside chroot() - and the published fix for that STILL is not working either.

I just don’t know how to get through to anyone that this is clearly NOT simply a ****ed configuration problem. If it were then COMMON SENSE TELLS YOU THAT IT WOULD AFFECT ONLY ONE DAEMON, NOT ALL THREE!!! Configurations, virtualusers, and authentications are all red herrings.

Whatever is causing this problem isn’t the daemons, but is something common to all three of them. What could THAT be?

(When you’re finished verifying that vsftpd is broken even worse than proftpd please let me know so I can get rid of vsftpd and put proftpd back in.)

If you follow exactly what I posted, you can have a working ftp supporting anonymous read/write.
You’ll also notice above I expressly said not to set up supporting a chroot because it will involve manually configuring permissions.

The way I see it, you’re just refusing to do what is easiest and assured working. You want to do something else, and with each variance you introduce something that might cause a problem and when that happens it’s something new that has to be addressed. When you say you are experiencing the same problem with all 3 different FTP apps,

  • You might be making the same mistake 3 separate times.
  • You might be mistaken that the 3 are exactly the same although they might at first appear to be the same.
  • You might be right that something common to how you’re installing and configuring all three, if this is the case then it should be the easiest to identify and fix… But I wonder if this is the case.

Is there some reason why you might not want to install as I recommended?
Is there some reason why you want to configure a writeable chroot?

Lastly,
You should stick with one FTP app only. If you do that, I can help you work through it… But if you jump from one FTP app to another, that’s too much to keep straight. I’d recommend opening up a separate thread for each FTP app if you want to try to find a solution for any or each.

TSU

I DID follow exactly what you posted, EACH AND EVERY TIME. Including when you insisted that I switch back to vsftpd even though I had previously indicated that I didn’t want to. I followed your instructions PRECISELY, and yet the ls command still causes the server to hang, and vsftpd still says vsftpd: refusing to run with writable root inside chroot() even though I expressly did not set up a chroot because I don’t need or want it. You only presume that I did.

The way I see it, you’re just refusing to do what is easiest and assured working. You want to do something else, and with each variance you introduce something that might cause a problem and when that happens it’s something new that has to be addressed. When you say you are experiencing the same problem with all 3 different FTP apps,

I haven’t refused to do ANYTHING. I pedantically followed EACH AND EVERY STEP YOU SUGGESTED, none of which did any good so far. How is that refusing anything? I’m still waiting for someone to suggest some actual diagnostic steps to locate and determine the actual cause of these problems, instead of just presumptuously assuming that I’m not following ‘configuration’ instructions.

How about some actual diagnostic steps, since it’s been firmly established that misconfiguration simply isn’t the cause of the problem?

CAN ANYONE ELSE OUT THERE PLEASE PITCH IN WITH SOME DIAGNOSTIC IDEAS? PLEASE?
I can’t believe that with all the people in this forum only one person can participate in this thread! Where’s all the system gurus?

  • You might be making the same mistake 3 separate times.

Probably. I tried following your suggestions exactly on each and every one of them. That tells me that the mistakes are in your suggestions.

  1. I tested vsftpd using ftp in a terminal and found that the ls
    command hangs the server until it times out. 1. I tested pure-ftpd using ftp in a terminal and found that the ls
    command hangs the server until it times out. 1. I tested proftpd using ftp in a terminal and found that it is not accessible due to the false chroot problem:
500 OOPS: vsftpd: refusing to run with writable root inside chroot()
Login failed.
421 Service not available, remote server has closed connection

This doesn’t allow getting to a prompt to enter the ls command.

  1. I tested all three servers using ftp in a terminal and found that the dir
    command also hangs the server in proftpd and pure-ftpd until it times out, and vsftpd is not accessible due to the false chroot problem. [ibid.] 1. I individually tested all three servers
    (one at a time) with every web browser on my system (including links,) and found that instead of getting a directory listing it hangs the server in proftpd and pure-ftpd until it times out , and vsftpd is not accessible only due to the false chroot problem. [ibid.]

How would that be “making the same mistake 3 separate times”? Nonsense!

  • You might be mistaken that the 3 are exactly the same although they might at first appear to be the same.

That is possible, except when you consider that I test and study the symptoms in each expressly to see if they’re the same or if something different happens. They’re each responding exactly the same - except for vsftpd, which additionally thinks I set up a chroot when I certainly did no such thing.

  • You might be right that something common to how you’re installing and configuring all three, if this is the case then it should be the easiest to identify and fix… But I wonder if this is the case.

Then I wonder how to diagnostically test and fix it, if it’s really so easy.

Is there some reason why you might not want to install as I recommended?

What in God’s name makes you presume that I didn’t?

Is there some reason why you want to configure a writeable chroot?

What in God’s name makes you presume that I configured a chroot AT ALL? I didn’t! That’s part of the problem! Why do I keep getting that error when I never configured any chroot at all? I guess I’ll never find out. Something somewhere in the system thinks I configured a chroot in vsftp when I didn’t. You presume the system’s error is right and I am wrong.
Here’s the relevant section from the config file, I copied it to show you that it didn’t get configured. Everything concerning chroot is still commented out. I did not enable chroot in Yast, and this proves it:

#
# You may specify an explicit list of local users to chroot() to their home
# directory. If chroot_local_user is YES, then this list becomes a list of
# users to NOT chroot().
#chroot_local_user=YES
#chroot_list_enable=YES
# (default follows)
#chroot_list_file=/etc/vsftpd.chroot_list
#
# Performs chroot with original (non-root) credentials. This is usefull on nfs with squash_root,
# where root becomes nobody and would need -x access.
#allow_root_squashed_chroot=YES
#

…yet I still get "vsftpd: refusing to run with writable root inside chroot()" even though clearly there’s no chroot enabled.

Lastly,
You should stick with one FTP app only.

I had already expressed that I want to do precisely that, but you INSISTED on me switching back to vsftpd instead. So that’s on you not me. I’m going back to proftpd since it doesn’t have any chroot problem and is easier to configure, and I have years of experience configuring it already.

If you do that, I can help you work through it… But if you jump from one FTP app to another, that’s too much to keep straight.

I agree. That’s why I said that I want to stick to using proftpd only. But you insisted that I change back to vsftpd instead, and now you’re blaming me for switching again. WTF?!!!

I’d recommend opening up a separate thread for each FTP app if you want to try to find a solution for any or each.

Good idea. Maybe I can get some fresh minds with fresh ideas that way. I’m getting exhausted trying to find solutions to far too many problems on this Leap 42.2, so many that I think they should have named it Flop 42.2. I have several weird problems with other things making me think there’s probably a connection. There’s problems with calibre, vuze, Compositor, X, and all my browsers as well as with the ls/dir command in ftp. I don’t think all these weird problems are just coincidences either. I just can’t figure out how they may all be connected. But opening a separate thread for each problem seems like it might be counterproductive should there be one common cause for all of it. I don’t want to dismiss that possibility a priory.

Now I will make a presumption of my own. I will now presume that besides just scolding me while presuming I wasn’t following your instructions when I actually was, that you also took the time to examine the ftp server and see that I did switch back to vsftp simply because you insisted on it. However, as I also stated in my previous reply, I will now permanently remove vsftp and will not ever try to use it again. I prefer proftpd since in 13.2 and all my previous installations I had only used proftpd, and like it. I don’t know what possessed me to allow the opensuse installer to default to installing vsftpd.

If you want to have one more go at vsftpd, I’m pretty sure you didn’t purge your system of vsftpd, and a manual setting you did earlier still exists on your system. You only posted the YAST config file which wouldn’t show your manual edits.

So,
I’d recommend

  1. Remove vsftpd
zypper rm vsftpd
  1. Now, make sure that vsftpd is removed. Either paste the following in a console or make a script that contains the following exactly and run it
rm /etc/logrotate.d/vsftpd \/etc/pam.d/vsftpd \
/etc/sysconfig/SuSEfirewall2.d/services/vsftpd \
/etc/vsftpd.conf \
/etc/xinetd.d/vsftpd \
/usr/lib/systemd/system/vsftpd.service \
/usr/lib/systemd/system/vsftpd.socket \
/usr/lib/systemd/system/vsftpd@.service \
/usr/sbin/rcvsftpd \
/usr/sbin/vsftpd \
/usr/share/omc/svcinfo.d/vsftpd.xml

Now, verify that vsftpd is removed. If you installed locate earlier as I suggested, you can now update your files database and search for anything with “vsftpd” in the name. The only things that might still exist on your system should be in a “doc” folder or man pages.** If you see anything that isn’t clearly documentation, post it and don’t go further**

updatedb && locate vsftpd

Only now install vsftpd using the steps I described in post #10.
EXCEPT for the YAST steps that configure support for only Anonymous logins.

TSU

All done, each step precisely as you instructed. (Exception - no welcome message so as to keep it short.) Result:

russ@behne:~> ftp behne.ddns.net
Connected to behne.ddns.net (112.208.141.200).
220 Welcome message
331 Please specify the password.
500 OOPS: vsftpd: refusing to run with writable root inside chroot()
Login failed.
421 Service not available, remote server has closed connection
ftp>

NB: Although the system was completely, thoroughly, carefully and pedantically purged as per your specific instructions above, and that the chroot box is NOT checked, yet I STILL get that ****ed error message.

OK,
Let’s take a look at basics…

Is your openSUSE its own unique physical machine not sharing with any other OS… Or a VPS or some other type of deployment that is provided by a Service Provider?
If this is some kind of VPS, please provide the name of the technology used (If not publicly documented, may require contacting support).
Was this machine created from source (ie. From an openSUSE DVD or openSUSE repos) or from an image? - And, if from an image who made it?

In other words, I am considering whether your entire installation is in a chroot and everything you’re doing is controlled by someone else.
Ordinarily, I assume that either the install is from source or in a fully isolated environment that allows full, unrestricted functionality within its environment but what you have may not be like that.

TSU

It’s one physical machine. No other OS installed, no dual-booting. No VPS.

The OS was downloaded from OpenSUSE, installed on a thumbdrive, plugged in then I rebooted thus loading the install program from the thumbdrive. A basic install was done, then upgrades done. After that repositories were added and my file list (which was previously saved in /home/user-packages.xml) was imported into the package manager, and then it finished installing remaining software. Then begins the task of getting dynamic DNS and all the servers working.

Sorry for the delay, I thought I answered this, but don’t see my reply so I’m resubmitting it again.

This is a lone box with opensuse Leap 42.2, no VPS or anything else.
I downloaded the install file from the opensuse site and used dd to put it on a stick, then booted from that to install. Last night I did the seventh format (since early December) of the root partition and reinstalled everything - again. (…reason is given below the line.)
Everything is right here in my box sitting in front of me, I have full access to everything.

[HR][/HR]Since our last communication, while waiting for another reply from you, I tried doing other work to recover the use of some unused space on the drive by using gparted-live-0.27.0-1-i686.iso installed on another stick to remove two unneeded partitions which were preventing me from formatting some unused space on the drive, then move the /usr/local partition. The gparted site failed to properly warn in advance on their download page that they fully knew that gparted-live-0.27.0-1 will not work on recent kernels and that it would break my system. It did, so I spent the past 24 hours rebuilding it and getting the proper version of gparted. Hopefully that will work so I can free up space and create 2 new larger and much needed partitions for /opt and /srv. So if I suddenly go silent again it just means that the older and recommended gparted-live-0.6.2-2.iso broke things again and it’ll take a day to recover. (Oh, what fun I’m having - not!)