There is a question that was unfortunately auto-closed without a solution but it is the EXACT same thing for me:
I can use and upload/download, edit basically all files in my nextcloud via the Web-GUI / Browser.
But as soon as I start using the Android client (regular playstore client, not F-droid) it will start preview-related HTTP 404 errors in the nginx access-log. Therfore the IP will be blocked by Fail2Ban.
I even deactivated previews via /nextcloud/config/config.php and restarted nginx as well as php-fpm. This does not help. The preview-related 404s are still showing up and leading to the IP being blocked.
Why does accessing the files via Android client cause these 404s while the web-gui does not have this issue? Is there a separate preview handling in the Android client that can not be deactivated?
android: are there any that do not result in a 404 (it’s perhaps an old cache on android)
gui: are there any requests to preview? If yes, do they always/never/sometimes result in a 404 error?
Question I’d like to answer with that is if the function itself is broken, if a client has an old filecache, if there is a possible bug in the client or the server.
Well, if it is disabled, then it’s no wonder that there is an 404. However, the android client should then stop using it. Perhaps something for the bug tracker (if that is not linked to your problem)
Hello all, hello tflidd. Short update on the issue:
It turned out: the Web client actually got locked out as well… So what happens:
My server is not only hosting Nextcloud but also Wordpress. That server is constantly being checked out by malicious clients trying to guess directories or send encoded POST requests.
All of this is then logged to the nginx access.log and error.log as either HTTP 400 (invalid request) or HTTP 404 - Not found.
So I decided to block any IP address that generates more than 2 HTTP 400 and/or 404. This rule / Filter was just recently added to fail2ban and I configured fail2ban to ignore my own I address so the issue did not show up while I was on my own LAN.
When working with Nextcloud from a remote location / with my phone, I got locked out. Turns out that Nextcloud is logging quite a lot of HTTP 404 (e.g. Thumbnails being one reason for that) and especially when working with OnlyOffice in a Docker container, there are also some HTTP 400.
So I toyed back and forth with the filters, trying to make them only catch the URLS referring to the Wordpress part. But then I would have my Nextcloud entirely unguarded. I also tried to add Nextcloud to an irnoreregex statement but SOME log entries generated by Nextcloud don’t have the full subdirectory so they can’t be filtered for. Which is a pity.
So now I needed to take a decision on how to deal with this and I decided to only block POST requests generting HTTP 400, as in these cases Nextcloud generally also has the subdirectory logged. Any GET command ending up with HTTP400 is ignored. I don’t like this but I don’t see any other way at this point.
My understanding is that most of these activities, that Nextcloud is logging, are hapening within the application contect, within PHP execution. Why do they have to end up in the nginx log? Why can’t nextcloud just push them to the dedicated Nextcloud log? That way one could focus on the nginx / HTTP requests for fail2ban and deal with Nextcloud messages separately?
Read → this post ← carefully please.
It contains a good filter for the wordpress backdoor scanner and how to get rid of them with fail2ban and nftables as action backend.