The logs folder is totally unrelated with nextcloud, but it contains sensitive date (access logs) and thus is password protected, done via basic htaccess authentication.
I used Google Chrome to open the logs folder (typing in username/password). Afterwards I continued testing my new nextcloud installation (created new users, did some logins and logouts). After a while, I noticed that logins took ridiculously long (like a whole minute) until the got processed. Did some research and found that it was brute-force-protection acting up.
Indeed, looking at the nextcloud logs, I found the problem. There were about 20 lines with the following warning:
“Warning core Login failed: ‘Log_Username’ (Remote IP: '220.127.116.11.55)”
I never entered this username into nextcloud, but the IP was matching with my own and the username was the same, I used for the logs folder. So my conclusion is that Google Chrome automatically sends usernames/password used in .htaccess to nextcloud and nextcloud falsely recognizes these requests as legit trials to log-in (wich of course it rejects).
Problem can easily avoided by closing Google Chrome after login to secondary site (and before opening nextcloud) and current brute-force-protection be reset by getting new IP. So it is no real issue for me.
Still, I think this is a bug and should not be like this. Thus I am reporting it here.