Can't run 3.1 with Docker

Hi Jordi,
Yeah, I understand your frustation having just burned a day trying to get this to work. I think your problem may be different to the one I've had - I've never actually hit a 404 error. In order, I've had:
1) A login page that wouldn't login. This was when the setup wasn't running and there was no database for it to find.
2) A 502 Bad Gateway error when the database was created but the company and user creations were failing during setup. I'm running behind a reverse proxy, so this is generally what I get when a database connection is FUBAR.
3) Custom 500 error pages when the app and database were both running, but the database was not coherent. This is what I fixed by going through and changing all the company_id fields to 1 instead of 8. I didn't have to mess with the user fields as I got it all working while I only had the one permitted user.

Anyway, I think I've been helped in diagnosis by not having a database full of existing records, and having a passing familiarity with PHP, so I've been happy to mess with the code and bash some SQL commands together knowing I wasn't going to lose anything.

If I can keep this stable, I think I'll use it for a bit in the hope of finding something more practical, knowing I've got the SQL database to extract from even if the app gets borked.

Love to know if you find anything suitable - no obligation to post back here obviously!

Hi Alyn, I also made some progress. The current tag 3.1.2-v works on my testing container, but does not work on my production one. I am not sure why.. as there are no config files.

I literally restored yesterdays backup to be used in testing and that works with the testing container. But when I updated the production container and use current DB I still have the 500s on transactions. When I tried to point the production container to the testing db, also does not work. Confusing..

Several of the latest transactions are made with the current only user. The other users are still in DB but have deleted_at column filled in so they cannot be found anywhere in akaunting. Transactions (or other items) created with those deleted users have just "Created by uknown.." as the creation note.

Be aware that since v3.1 the software is under different license. They wanted to protect themselves against rebranding the whole thing with this so I guess that making it work does not violate it.

Can you make a backup of the empty initialized db so others might be able to use it without the necessary changes to code? I am using this to backup all my dbs - https://hub.docker.com/r/tiredofit/db-backup/ but I guess there is also an option in phpmyadmin.

So the testing container worked because it's db got properly updated! The is at least new table _contact_persons that is not present in 3.0.x. Unfortunately my image got updated with the latest digest and the current one does not upgrade the db properly and that is why the production did not work when I switched.

The that is not happening migration is described here. https://github.com/akaunting/akaunting/blob/master/database/migrations/2023_10_03_000000_core_v310.php

Might it be that I am jumping from 3.0.17 straight to 3.1.2? The testing container went through hell and back actually with different versions. But I also recovered the backup from production. That is tasks for tomorrow for me.

Happening the same error to me:

Setting locale en-US
Creating database tables
Connecting to database akaunting@akaunting-db:3306
Creating company
In CreateCompany.php line 61:

Not able to create a new user.

I finally got the app running locally using docker.

- Had to upgrade my docker daemon to run the maria DB
- I downloaded and unzipped the latest release from the URL in the Dockerfile. Place these files in 'files/html' so you can edit them
- Change 'APP_ENV' to 'local' in the .env file
- in Plans.php.getPlanLimitByType adjust it so that it runs in testing/console mode
- Remove the zip download and unpacking lines in the 'Dockerfile' file. You already manually completed this step
- Copy and edit the db.env and run.env files PER the docker instructions in github.
- Since you're running local, make sure to use non https IP address for the app url. And the default port configured for docker is 8080
- Remove the previous containers and volumes related to akaunting then run "sudo AKAUNTING_SETUP=true docker-compose up -d --build; sleep 25; sudo docker-compose down; sudo docker-compose up -d"
- Sleep may need to be longer for slower machines. This is to allow the app to configure itself.

You should then be able to log in and set your api key in the wizard. I'm pretty sure once it's set, you can revert all the php code.

How can I do this step:
- in Plans.php.getPlanLimitByType adjust it so that it runs in testing/console mode

Can you share that function code?
Thanks

I have some good news, well at least its finally working without spewing errors...

Edit your docker-compose.yml and change version from :latest to :3.0.15. Appears to be the last good working build. Your Welcome!

From this
docker.io/akaunting/akaunting:latest

To this
docker.io/akaunting/akaunting:3.0.15

# Warning: Code Snippet - Presumed Fresh (No Data) Stack
# Warning: Destructive Volume/Data Action #################
docker compose down
docker volume rm akaunting_akaunting-data akaunting_akaunting-db
nano docker-compose.yml
AKAUNTING_SETUP=true docker compose up -d
docker compose logs -f
# Warning: Destructive Volume/Data Action #################

Issue raised: https://github.com/akaunting/docker/issues/101

For docker follow the tutorial below
https://github.com/akaunting/docker

- Create env files
- In run.env file add
APP_INSTALLED=false
- Then run
AKAUNTING_SETUP=true docker-compose up -d
Do the setup as instructed
After setup
Comment this variable in run.env file
#APP_INSTALLED=false
Then run
docker-compose down
docker-compose up -d