No Admin Login after first installation

Hello everyone, I’m a newcomer to the Linux and Nextcloud community, seeking help with an issue:
VM-1: Ubuntu 22.04 LTS VM (VM 1) running Nextcloud 28.0.1 with php8.2 and NGINX.
VM-2: Serving as a DB server with MariaDB for a Nextcloud database.

After overcoming initial installation challenges, I encountered an issue where attempting to log in with the newly created Nextcloud admin account results in no response. Investigation revealed that my IP address is blocked and listed in the “oc_bruteforce_attempts” table. Despite attempting to reset entries using the command “sudo -u www-data php /var/www/nextcloud/occ security:bruteforce:reset XXX.XXX.XXX.XXX,” I still cannot access my Nextcloud.

I have desperately tried to disable the brute force protection in the Nextcloud config.php, but unfortunately, without success. This is probably not a viable solution.

I would be incredibly grateful if you could point me in the right direction and help me learn something in the process. Thank you very much for your assistance.

Doesn’t anyone have at least a clue as to which direction I need to go to solve the problem?

You didn’t fill out the support template so your post probably got overlooked.

Please post the output of:

  • occ config:list system
  • occ app:list
  • the last couple lines from your nextcloud.log during one of these login attempts
  • your browser console during one of these logins attempts
  • your browser console network tab one of these login attempts

The brute force protection does not prevent log-in; it merely slows down log-ins to make brute force password/account guessing attempts take longer.[1]

That said, if you are unexpectedly triggering brute force protection, the most common cause of this is a misconfiguration with the reverse proxy and trusted_proxies parameters or associated proxy header parameters[2].

I encountered an issue where attempting to log in with the newly created Nextcloud admin account results in no response.

My suspicion is something else is going on and your Nextcloud Server log and/or browser console/network tabs will be informative.

[1] Brute force protection — Nextcloud latest Administration Manual latest documentation
[2] Brute force protection — Nextcloud latest Administration Manual latest documentation

1 Like

The last couple lines from your nextcloud.log during one of these login attempts Can help you to get in the right direction.

Can you provide us with it?

1 Like

Hello jtr, I want to thank you from the bottom of my heart for responding to my issue because I am truly feeling very desperate and don’t know where else to turn for advice.
Thank you for mentioning the support template. Since I’m new here, I’m still a bit overwhelmed.

Now, back to my issue:
I now suspect that the installation of Nextcloud didn’t go through properly. The system is telling me it can’t find the ‘occ’ command, and the ‘nextcloud.log’ file is completely empty.

My mistake probably lies in the faulty “nextcloud.conf” located at /etc/nginx/conf.d.

server {
    listen 80;
    listen [::]:80;
    #server_name XXX.XXX.XXX.XXX;

    # Add headers to serve security related headers
    #add_header Strict-Transport-Security "max-age=31536000" always;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Robots-Tag none;
    add_header X-Download-Options noopen;
    add_header X-Permitted-Cross-Domain-Policies none;
    add_header Referrer-Policy no-referrer;

    #I found this header is needed on Ubuntu, but not on Arch Linux.
    add_header X-Frame-Options "SAMEORIGIN";

    # Path to the root of your installation
    root /var/www/nextcloud/;

    access_log /var/log/nginx/nextcloud.access;
    error_log /var/log/nginx/nextcloud.error;

    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;

    # The following 2 rules are only needed for the user_webfinger app.
    # Uncomment it if you're planning to use this app.
    #rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
    #rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json
    # last;

    location = /.well-known/carddav {
        return 301 $scheme://$host/remote.php/dav;
    location = /.well-known/caldav {
       return 301 $scheme://$host/remote.php/dav;

    location ~ /.well-known/acme-challenge {
      allow all;

    # set max upload size
    client_max_body_size 512M;
    fastcgi_buffers 64 4K;
   # Disable gzip to avoid the removal of the ETag header
    gzip off;

    # Uncomment if your server is build with the ngx_pagespeed module
    # This module is currently not supported.
    #pagespeed off;

    error_page 403 /core/templates/403.php;
    error_page 404 /core/templates/404.php;

    location / {
       rewrite ^ /index.php;

    location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
       deny all;
    location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
       deny all;

    location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+|core/templates/40[34])>
       include fastcgi_params;
     fastcgi_split_path_info ^(.+\.php)(/.*)$;
       try_files $fastcgi_script_name =404;
       fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
       fastcgi_param PATH_INFO $fastcgi_path_info;
       #Avoid sending the security headers twice
       fastcgi_param modHeadersAvailable true;
       fastcgi_param front_controller_active true;
       fastcgi_pass unix:/run/php/php8.2-fpm.sock;
       fastcgi_intercept_errors on;
       fastcgi_request_buffering off;

    location ~ ^/(?:updater|ocs-provider)(?:$|/) {
       try_files $uri/ =404;
       index index.php;

    # Adding the cache control header for js and css files
    # Make sure it is BELOW the PHP block
    location ~* \.(?:css|js)$ {
        try_files $uri /index.php$uri$is_args$args;
        add_header Cache-Control "public, max-age=7200";
        # Add headers to serve security related headers (It is intended to
        # have those duplicated to the ones above)
        add_header X-Content-Type-Options nosniff;
       add_header X-XSS-Protection "1; mode=block";
        add_header X-Robots-Tag none;
        add_header X-Download-Options noopen;
        add_header X-Permitted-Cross-Domain-Policies none;
        add_header Referrer-Policy no-referrer;
        # Optional: Don't log access to assets
        access_log off;

   location ~* \.(?:svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$ {
        try_files $uri /index.php$uri$is_args$args;
        # Optional: Don't log access to other assets
        access_log off;

I know that this config deviates significantly from the Nextcloud guide, but initially, I want to set up Nextcloud without SSL and Let’s Encrypt (just within the local network) and then later integrate SSL using a certificate from the firewall. Therefore, I attempted to adjust the config without much sense and threw everything together that I found.

I hope you or someone else can give me some advice and maybe explain some necessary basics in a way that I can learn and understand.

Thank you very much for your continued help and time.

One question: How did you created a new admin account?
Besides the already existing admin account? or …

Do you mean the admin account for Nextcloud? Isn’t that created through the input in the web installer? Or which admin account are you referring to?

[quote=“Newbie_GER, post:1, topic:180707”]
You mentioned in the issue you raised, you “encountered an issue where attempting to log in with the newly created Nextcloud admin account”.

  • So that is why I am asking how you have created this new admin account in Nextcloud.

You also mentioned you initially installed NC without SSL certificate and have it handled externally by your firewall.

  • Can you indicated after which configuration change the problem appeared?

Okay. Now we’re getting somewhere.

If you don’t want to use HTTPS, you should be able to take the example configuration and just:

  • remove the enforce HTTPS line from the first server section to no longer redirect to HTTPS
  • shift the bulk of the configuration (i.e. everything in the second server section) up into the first server section
  • remove the few lines that are HTTPS specific (e.g. listen 443 and ssl_*
1 Like

Please let us know if you found the solution given by jtr.
It is always nice to see if a problem has been solved…
Greetings …

1 Like

Hello folks, apologies for the late response, but unfortunately, I haven’t had the chance to do so earlier. The problem still persists, unfortunately.
To configure properly and based on the official documentation, I took it as a basis and tried to modify it according to your statements… or at least as far as I understood it. Some things I’ve simply commented out so that I can easily “turn them on” again once I can focus on SSL and certificates again.

upstream php-handler {
    server unix:/run/php/php8.2-fpm.sock;

# Set the `immutable` cache control options only for assets with a cache busting `v` argument
map $arg_v $asset_immutable {
    "" "";
    default "immutable";

server {
    listen 80;
    listen [::]:80;
    server_name FQSN;

    # Prevent nginx HTTP Server Detection
    server_tokens off;

    # Enforce HTTPS
    #return 301 https://$server_name$request_uri;

#server {
#    listen 443      ssl http2;
#    listen [::]:443 ssl http2;
#    server_name FQSN;

    # Path to the root of your installation
    root /var/www/nextcloud;

    # Use Mozilla's guidelines for SSL/TLS settings
    #ssl_certificate     /etc/ssl/nginx/;
    #ssl_certificate_key /etc/ssl/nginx/;

    # Prevent nginx HTTP Server Detection
    #server_tokens off;

    # HSTS settings
    # WARNING: Only add the preload option once you read about
    # the consequences in This option
    # will add the domain to a hardcoded list that is shipped
    # in all major browsers and getting removed from this list
    # could take several months.
    #add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload" always;

   # set max upload size and increase upload timeout:
    client_max_body_size 512M;
    client_body_timeout 300s;
    fastcgi_buffers 64 4K;

    # Enable gzip but do not remove ETag headers
    gzip on;
    gzip_vary on;
    gzip_comp_level 4;
    gzip_min_length 256;
    gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
    gzip_types application/atom+xml text/javascript application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/>

    # Pagespeed is not supported by Nextcloud, so if your server is built
    # with the `ngx_pagespeed` module, uncomment this line to disable it.
    #pagespeed off;

    # The settings allows you to optimize the HTTP2 bandwidth.
    # See
    # for tuning hints
    client_body_buffer_size 512k;

    # HTTP response headers borrowed from Nextcloud `.htaccess`
    add_header Referrer-Policy                   "no-referrer"       always;
    add_header X-Content-Type-Options            "nosniff"           always;
    add_header X-Frame-Options                   "SAMEORIGIN"        always;
    add_header X-Permitted-Cross-Domain-Policies "none"              always;
    add_header X-Robots-Tag                      "noindex, nofollow" always;
    add_header X-XSS-Protection                  "1; mode=block"     always;

    # Remove X-Powered-By, which is an information leak
    fastcgi_hide_header X-Powered-By;

    # Add .mjs as a file extension for javascript
    # Either include it in the default mime.types list
    # or include you can include that list explicitly and add the file extension
    # only for Nextcloud like below:
    include mime.types;
    types {
        text/javascript js mjs;

    # Specify how to handle directories -- specifying `/index.php$request_uri`
    # here as the fallback means that Nginx always exhibits the desired behaviour
    # when a client requests a path that corresponds to a directory that exists
    # on the server. In particular, if that directory contains an index.php file,
    # that file is correctly served; if it doesn't, then the request is passed to
    # the front-end controller. This consistent behaviour means that we don't need
    # to specify custom rules for certain paths (e.g. images and other assets,
    # `/updater`, `/ocs-provider`), and thus
    # `try_files $uri $uri/ /index.php$request_uri`
    # always provides the desired behaviour.
    index index.php index.html /index.php$request_uri;

    # Rule borrowed from `.htaccess` to handle Microsoft DAV clients
    location = / {
        if ( $http_user_agent ~ ^DavClnt ) {
            return 302 /remote.php/webdav/$is_args$args;

    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;

    # Make a regex exception for `/.well-known` so that clients can still
    # access it despite the existence of the regex rule
    # `location ~ /(\.|autotest|...)` which would otherwise handle requests
    # for `/.well-known`.
    location ^~ /.well-known {
        # The rules in this block are an adaptation of the rules
        # in `.htaccess` that concern `/.well-known`.

        location = /.well-known/carddav { return 301 /remote.php/dav/; }
        location = /.well-known/caldav  { return 301 /remote.php/dav/; }

        location /.well-known/acme-challenge    { try_files $uri $uri/ =404; }
        location /.well-known/pki-validation    { try_files $uri $uri/ =404; }

        # Let Nextcloud's API for `/.well-known` URIs handle all other
        # requests by passing them to the front-end controller.
        return 301 /index.php$request_uri;

    # Rules borrowed from `.htaccess` to hide certain paths from clients
    location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/)  { return 404; }
    location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console)                { return 404; }

   # Ensure this block, which passes PHP files to the PHP process, is above the blocks
    # which handle static assets (as seen below). If this block is not declared first,
    # then Nginx will encounter an infinite rewriting loop when it prepends `/index.php`
    # to the URI, resulting in a HTTP 500 error response.
    location ~ \.php(?:$|/) {
        # Required for legacy support
        rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|ocs-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;

        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        set $path_info $fastcgi_path_info;

        try_files $fastcgi_script_name =404;

        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $path_info;
        #fastcgi_param HTTPS on;

        fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
        fastcgi_param front_controller_active true;     # Enable pretty urls
        fastcgi_pass php-handler;

        fastcgi_intercept_errors on;
        fastcgi_request_buffering off;

        fastcgi_max_temp_file_size 0;

    # Serve static files
    location ~ \.(?:css|js|mjs|svg|gif|png|jpg|ico|wasm|tflite|map|ogg|flac)$ {
        try_files $uri /index.php$request_uri;
        add_header Cache-Control "public, max-age=15778463, $asset_immutable";
        access_log off;     # Optional: Don't log access to assets

        location ~ \.wasm$ {
            default_type application/wasm;

    location ~ \.woff2?$ {
        try_files $uri /index.php$request_uri;
        expires 7d;         # Cache-Control policy borrowed from `.htaccess`
        access_log off;     # Optional: Don't log access to assets

    # Rule borrowed from `.htaccess`
    location /remote {
        return 301 /remote.php$request_uri;

    location / {
        try_files $uri $uri/ /index.php$request_uri;

When I check the configuration with “nginx -t”, I only get the following warning message:

nginx: [warn] duplicate extension “js”, content type: “text/javascript”, previous content type: “application/javascript” in /etc/nginx/conf.d/nextcloud.conf:88
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

I thank you for your patience and the opportunity to learn through this troubleshooting process.

If I’ve understood the entire setup and dependencies of a Nextcloud installation correctly, there are indeed a few key points crucial for a proper installation:

  1. Proper configuration of NGINX in the file (in my case) /etc/nginx/conf.d/nextcloud.conf (as mentioned above).
    Could it be that I need to adjust something in the file /etc/nginx/nginx.conf? Because mine looks like this:
user www-data;
worker_processes auto;
pid /run/;
include /etc/nginx/modules-enabled/*.conf;

events {
        worker_connections 768;
        # multi_accept on;

http {

        # Basic Settings

        sendfile on;
        tcp_nopush on;
        types_hash_max_size 2048;
        # server_tokens off;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        # SSL Settings

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

        # Logging Settings

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        # Gzip Settings

        gzip on;

        # gzip_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

        # Virtual Host Configs

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;

#mail {
#       # See sample authentication script at:
#       #
#       # auth_http localhost/auth.php;
#       # pop3_capabilities "TOP" "USER";
#       # imap_capabilities "IMAP4rev1" "UIDPLUS";
#       server {
#               listen     localhost:110;
#               protocol   pop3;
#               proxy      on;
#       }
#       server {
#               listen     localhost:143;
#               protocol   imap;
#               proxy      on;
#       }

Could it be that the configurations here are conflicting with each other? Because my “nextcloud.conf” is just being included in the “nginx.conf”. Are there any best practices for how to do this most effectively?

  1. The “config.php” file of Nextcloud under /var/www/nextcloud/config.
$CONFIG = array (
  'instanceid' => 'XXXX',
  'passwordsalt' => 'XXXX',
  'secret' => 'XXXX',
  'trusted_domains' =>
  array (
    0 => 'FQSN',
    1 => '',
    2 => '',
    3 => ''
  'datadirectory' => '/var/www/nextcloud/data',
  'dbtype' => 'mysql',
  'version' => '',
  'overwrite.cli.url' => 'http://FQSN',
  'dbname' => 'nextcloud',
  'dbhost' => 'DB-FQSN:3306',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'DBUSER',
  'dbpassword' => 'DBPASSWORD',
  'installed' => true,
  '' => 'false',
  'brute_force_detection_ban_enabled' => 'false',

In the “trusted domains” section, I entered the FQSN (Fully Qualified Subdomain Name) of the Nextcloud, the internal IP address, and the internal IP addresses of the PCs from which I access it (as a test, because I didn’t know how else to fix it). I manually changed the DB user and the DB password afterwards. Maybe that was also wrong? I think previously there were hash values there?

It’s just a warning; you can ignore it. Or, if you like, remove js from this line:

    types {
        text/javascript js mjs;


    types {
        text/javascript mjs;

It doesn’t seem to be my main issue. Do the configuration files look correct so far, or have I done something wrong that’s preventing it from working? Because my core issue, not being able to log in to the Nextcloud web interface, still persists.

Is there a reason that you’ve opted to use the more complicated (and not formally supported) deployment model of Nginx + FPM?

I only ask because you said you’re a newer user. Since you’re already running into a lot of challenges, it might make sense to do a more conventional installation.

Anyhow, I don’t recall all the specifics of your situation offhand, but are you still unable to access your Nextcloud log?

Based on your previously provided config, I would expect it to be /var/www/nextcloud/data/nextcloud.log

I would also look at your Nginx access log and error log as well as your browser console (as suggested previously) for clues.

These login transactions are going somewhere. There will be evidence in the logs or console.

1 Like

Hello everyone and thank you very much for the many helpful tips and advice. I have discarded my entire installation and started over from scratch. I have now used Apache as the web server instead of Nginx and managed to set up a functional Nextcloud following various guides.
While there isn’t a definitive solution to my problem, I’m fine with closing the matter for now.