Can't login to AIO for last couple of days making my data inaccesible

  • Nextcloud AIO version
    • latest docker image (20250927_081431)
  • Operating system and version (e.g., Ubuntu 24.04):
    • Ubuntu Server 24.04.1
  • Is this the first time you’ve seen this error? (Yes / No):
    • Yes
  • When did this problem seem to first start?
    • ~3 days ago
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • AIO
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • No

Summary of the issue you are facing

I have a script that has been running for last year stopping the containers, backing everything up and restarting it. Since around 3 days ago after the script ran I’m unable to login to the AIO interface anymore making my nextcloud data inaccessible.

Error appears when doing following

  • Navigate to the AIO UI via an IP address of the server
  • Enter the password (both the right password and wrong one produce the same behavior) hit “Log in”
  • Log below will pop up on mastercontainer and AIO UI gets refreshed without any message

Log entries

Nextcloud AIO Mastercontainer

NOTICE: PHP message: Slim Application Error
Type: TypeError
Code: 0
Message: AIO\Data\ConfigurationManager::GetPassword(): Return value must be of type string, null returned
File: /var/www/docker-aio/php/src/Data/ConfigurationManager.php
Line: 24
Trace: #0 /var/www/docker-aio/php/src/Auth/AuthManager.php(18): AIO\Data\ConfigurationManager->GetPassword()
#1 /var/www/docker-aio/php/src/Controller/LoginController.php(25): AIO\Auth\AuthManager->CheckCredentials('a')
#2 /var/www/docker-aio/php/vendor/slim/slim/Slim/Handlers/Strategies/RequestResponse.php(39): AIO\Controller\LoginController->TryLogin(Object(GuzzleHttp\Psr7\ServerRequest), Object(GuzzleHttp\Psr7\Response), Array)
#3 /var/www/docker-aio/php/vendor/slim/slim/Slim/Routing/Route.php(362): Slim\Handlers\Strategies\RequestResponse->__invoke(Array, Object(GuzzleHttp\Psr7\ServerRequest), Object(GuzzleHttp\Psr7\Response), Array)
#4 /var/www/docker-aio/php/vendor/slim/slim/Slim/MiddlewareDispatcher.php(73): Slim\Routing\Route->handle(Object(GuzzleHttp\Psr7\ServerRequest))
#5 /var/www/docker-aio/php/vendor/slim/slim/Slim/MiddlewareDispatcher.php(73): Slim\MiddlewareDispatcher->handle(Object(GuzzleHttp\Psr7\ServerRequest))
#6 /var/www/docker-aio/php/vendor/slim/slim/Slim/Routing/Route.php(321): Slim\MiddlewareDispatcher->handle(Object(GuzzleHttp\Psr7\ServerRequest))
#7 /var/www/docker-aio/php/vendor/slim/slim/Slim/Routing/RouteRunner.php(74): Slim\Routing\Route->run(Object(GuzzleHttp\Psr7\ServerRequest))
#8 /var/www/docker-aio/php/vendor/slim/csrf/src/Guard.php(482): Slim\Routing\RouteRunner->handle(Object(GuzzleHttp\Psr7\ServerRequest))
#9 /var/www/docker-aio/php/vendor/slim/slim/Slim/MiddlewareDispatcher.php(178): Slim\Csrf\Guard->process(Object(GuzzleHttp\Psr7\ServerRequest), Object(Slim\Routing\RouteRunner))
#10 /var/www/docker-aio/php/vendor/slim/twig-view/src/TwigMiddleware.php(117): Psr\Http\Server\RequestHandlerInterface@anonymous->handle(Object(GuzzleHttp\Psr7\ServerRequest))
#11 /var/www/docker-aio/php/vendor/slim/slim/Slim/MiddlewareDispatcher.php(129): Slim\Views\TwigMiddleware->process(Object(GuzzleHttp\Psr7\ServerRequest), Object(Psr\Http\Server\RequestHandlerInterface@anonymous))
#12 /var/www/docker-aio/php/src/Middleware/AuthMiddleware.php(36): Psr\Http\Server\RequestHandlerInterface@anonymous->handle(Object(GuzzleHttp\Psr7\ServerRequest))
#13 /var/www/docker-aio/php/vendor/slim/slim/Slim/MiddlewareDispatcher.php(283): AIO\Middleware\AuthMiddleware->__invoke(Object(GuzzleHttp\Psr7\ServerRequest), Object(Psr\Http\Server\RequestHandlerInterface@anonymous))
#14 /var/www/docker-aio/php/vendor/slim/slim/Slim/Middleware/ErrorMiddleware.php(77): Psr\Http\Server\RequestHandlerInterface@anonymous->handle(Object(GuzzleHttp\Psr7\ServerRequest))
#15 /var/www/docker-aio/php/vendor/slim/slim/Slim/MiddlewareDispatcher.php(129): Slim\Middleware\ErrorMiddleware->process(Object(GuzzleHttp\Psr7\ServerRequest), Object(Psr\Http\Server\RequestHandlerInterface@anonymous))
#16 /var/www/docker-aio/php/vendor/slim/slim/Slim/MiddlewareDispatcher.php(73): Psr\Http\Server\RequestHandlerInterface@anonymous->handle(Object(GuzzleHttp\Psr7\ServerRequest))
#17 /var/www/docker-aio/php/vendor/slim/slim/Slim/App.php(209): Slim\MiddlewareDispatcher->handle(Object(GuzzleHttp\Psr7\ServerRequest))
#18 /var/www/docker-aio/php/vendor/slim/slim/Slim/App.php(193): Slim\App->handle(Object(GuzzleHttp\Psr7\ServerRequest))
#19 /var/www/docker-aio/php/public/index.php(198): Slim\App->run()
#20 {main}
Tips: To display error details in HTTP response set "displayErrorDetails" to true in the ErrorHandler constructor.

My password is not a as logs might suggest but I get the same error regardless of entering correct or incorrect password. The error suggests that the password is not set at all.

Any help is appreciated.

Hi, it sounds like the configuration.json got broken somehow. Can you check its content via sudo docker run -it --rm --volume nextcloud_aio_mastercontainer:/mnt/docker-aio-config:rw alpine sh -c "apk add --no-cache nano && nano /mnt/docker-aio-config/data/configuration.json"

It must have a key password

Hi, thank you for your response. Yes, I already checked configuration file when I was trying to check the current password and I don’t have password key. My configuration.json looks like this

{
    "secrets": {
        "REDIS_PASSWORD": "abc123...",
        "DATABASE_PASSWORD": "abc123...",
        "ONLYOFFICE_SECRET": "abc123...",
        "RECORDING_SECRET": "abc123...",
        "IMAGINARY_SECRET": "abc123...",
        "NEXTCLOUD_PASSWORD": "abc123...",
        "TURN_SECRET": "abc123...",
        "SIGNALING_SECRET": "abc123...",
        "FULLTEXTSEARCH_PASSWORD": "abc123...",
        "WHITEBOARD_SECRET": "abc123..."
    },
    "nextcloud_datadir": "/mnt/nextcloud/nextcloud_aio_data"
}

Hm… can you try to restore a working configuration.json that includes the password key from a backup?

Thanks, that solved the issue. I’m able to login and everything runs as before. I ran the backup script as well and the contents of the configuration file were preserved.

Do you know why this could have happened or rather at which point? I’d like to investigate further myself. The script that I run doesn’t write any data to the instance - only sends the backed up archive further. Maybe, master AIO container somehow didn’t find the configuration file at startup and just created the new one - unfortunately I don’t have the master container logs from right before when it first happened.