Redefining TimeoutIdle or TimeoutNoTransfer in a configuration file inside /etc/proftpd/conf.d/, after they’ve already been defined in /etc/proftpd/proftpd.conf, fails to change those values for the daemon — that is, after restarting the daemon, the values for those parameters remain as those set in /etc/proftpd/proftpd.conf.

At least TimeoutIdle or TimeoutNoTransfer are affected. TimeoutSession and TimeoutLogin, which (in stock 16.04) haven’t been defined in the master configuration file can be set effectively, but setting them first in the master file, then again to different values inside conf.d reveals them to be equally affected.

On the other hand, (at least) ServerName *can* be overridden in the custom configuration file, so the handling of different configuration knobs in this regard seems to be inconsistent.

Steps to reproduce:
1. Create a /etc/proftpd/conf.d/proftpd.conf with the following lines:
TimeoutIdle 10
TimeoutNoTransfer 10
2. Restart proftpd
3. Log into the server, wait 11 seconds

What I expect to happen:
To get kicked out of the server.

What happens instead:
I’m allowed to linger on the server, presumably for the 600 seconds defined for TimeoutNoTransfer in /etc/proftpd/proftpd.conf.

The Include directive, when given a directory as parameter (such as /etc/proftpd/conf.d/, as in the stock /etc/proftpd/proftpd.conf), causes all files in said directory to be read, not just ones ending in .conf. This causes problems if, for instance, I’m using vim to edit a file in the included directory while the proftpd service is being (re)started: vim stores a .swp file in the same directory, and proftpd may fail to start with ”fatal: unknown configuration directive” when it tries to parse the .swp file.

Those scripts are ran from the initrd, so it’s looking for plymouth and plymouthd in the initrd /bin and /sbin directories, and those are probably missing the said files just as the error message says.

/usr/share/initramfs-tools/hooks/plymouth is responsible for copying the plymouth executables onto the initrd, so to see why it fails to copy the files, I added `set -x` to it and then ran `update-initramfs -v -u`.

In my case (I’m running Kodibuntu, I recently upgraded the underlying system from 14.04 to 16.04) the issue was that the hook failed to find Kodibuntu theme files for Plymouth, because it was looking for them in /usr/share/plymouth/themes (which apparently is the standard place), whereas the files actually resided in /lib/plymouth/themes for some (legacy?) reason. The hook therefore determined that I have no working Plymouth theme and thus don’t need the executables.

After moving the theme files to /usr/share/plymouth/themes (and some manual labor updating references in the files themselves as well as Plymouth’s alternatives) the hook now correctly finds those files and then proceeds to copy the Plymouth executables onto the initrd.

Haven’t seen this once since upgrading to 16.04 back in April, so I’m pretty sure the issue has been fixed. Yay!

So I did some more digging and turns out this was all due to my having botched the migration. I had used the experimental upgrader script, which kept failing due to timeouts, so I went ahead and tried to finish it up manually. With everything else apart from the Android app working as expected, I was fooled into thinking I had nailed it. But with this issue persisting, I just had to check, and wouldn’t you know, there were still all these files lingering from the previous Owncloud installation that I hadn’t replaced.

Tl;dr; re-downloaded 9.0.52, replaced the existing installation with the files extracted from the download, and the Android app now also connects without issue.

@HucSte, I’m not sure your issue is related, but if you also migrated from Owncloud, you could try re-installing Nextcloud files afresh.

No worries, thanks for taking a look at this @tobiasKaminsky!

Forgot to mention that my installation is served over https too, on Apache. But for me there are no SSL errors to be seen either.

I just migrated from Owncloud 8.2 to Nextcloud 9.0.52. Everything else (i.e. the web interface, desktop client) seems to work just fine, but I can’t get the Nextcloud Android app to connect with the server. I can enter the URL (no errors), my login and password, but the ”Connect” button feels totally unresponsive, it does nothing at all no matter how much I tap it. No error messages are given by the app nor is there anything correlating with the attempts in server logs.

This happens on both my phone (Nexus 5X, Android M) and tablet (Samsung Tab 4, Android L). I also tried the Beta app from F-Droid and the issue is present there too. It’s also present in both my WLAN and when using a direct 3G connection on the phone (so I don’t think the WLAN router’s firewall is the cause either).

The Owncloud app on the same devices still works with the server, although I haven’t tried logging out and re-connecting it.

The server is on shared hosting where I have shell access.

Any suggestions?

Ai niin, ja valkoisia. Ostin ne valkoiset.

Minä olisin toissapäivänä halunnut punaiset Converse-kloonit, mutta Prisman miesten osastolla oli vain mustia, sinisiä ja farkkukuvioisia, ja naisten hyllyn punaiset olivat liian pieniä.

Kiitos kun sain avautua.