tuxgasy / docker-dolibarr

Use the official repo https://github.com/Dolibarr/dolibarr-docker
GNU General Public License v3.0
129 stars 92 forks source link

Error: Table 'dolibarr.llx_user' doesn't exist #125

Closed Mohamed-Hammada closed 1 month ago

Mohamed-Hammada commented 1 year ago

I encountered an error while trying to log in to my Dolibarr application after running it with Docker Compose. The error message states: "Table dolibarr.llx_user doesn't exist."

Steps to Reproduce:

1- Set up the Docker Compose configuration with the provided YAML file. 2- Run the Docker Compose command: docker-compose up.

Expected Behavior: After running the Docker Compose command, I expect to be able to log in to the Dolibarr application without any errors.

Actual Behavior: Upon trying to log in, I receive the error message: "Table 'dolibarr.llx_user' doesn't exist."

Additional Information:

version: "3.8"

networks:
  internal-pod:
    internal: true
  external-pod:
    internal: false

volumes:
  dolibarr-custom:
  dolibarr-docs:
  mysql-data:

services:
  dolibarr:
    image: tuxgasy/dolibarr:latest
    environment:
      DOLI_DB_HOST: "mysql"
      DOLI_DB_HOST_PORT: "3306"
      DOLI_DB_USER: "dolibarr"
      DOLI_DB_PASSWORD: "mysupersecretpasswordfordatabase"
      DOLI_DB_NAME: "dolibarr"
      DOLI_ADMIN_LOGIN: "admin"
      DOLI_ADMIN_PASSWORD: "mysuperhypersecretpasswordforadminacount"
    ports:
      - 80:80
    volumes:
      - dolibarr-docs:/var/www/documents
      - dolibarr-custom:/var/www/html/custom
    networks:
      - internal-pod
      - external-pod

  mysql:
    image: library/mariadb:latest
    environment:
      MYSQL_DATABASE: "dolibarr"
      MYSQL_USER: "dolibarr"
      MYSQL_PASSWORD: "mysupersecretpasswordfordatabase"
      MYSQL_ROOT_PASSWORD: "mysupersupersecretpasswordforrootuser"
    volumes:
      - mysql-data:/var/lib/mysql
    ports:
      - 3306:3306
    networks:
      - internal-pod
      - external-pod
alexander-sml commented 1 year ago

I got the same error when I tried to start service + psql db

Mohamed-Hammada commented 1 year ago

I believe the problem is not specific to any particular type of database; rather, it appears to affect all databases.

tcj-one commented 1 year ago

This is a crippling issue that has affected me a couple of times, and seems unrecoverable. All I can do is restore my entire VM to a snapshot when it was working.

Anyone know why this happens or how to recover more gracefully?

tcj-one commented 1 year ago

Doing some additional digging, and it seems that there are no tables in the database. Somewhere sometimes somehow, during reboot or update, all tables are dropped. Not sure if this is unique to this docker image, or a dolibarr problem, but I think this is the only thread about this particular issue.

Screenshot 2023-08-04 at 1 59 44 PM
JiroMusik commented 1 year ago

Today I was confronted with this error, the system was running fine for weeks now. A ERP software deleting its own data by accident? How can that be?

tcj-one commented 1 year ago

Did you do any kind of docker updates or system updates or a reboot or anything? I'm not sure what causes it, but I've also lost my data again.

I had some snapshots and went back in time far enough that I could boot, exported the database, when back to the present, and just imported the database back in. But obviously this is extremely cumbersome and should be unnecessary.

JiroMusik commented 1 year ago

No updates or anything, I was working on it just 6 hours before.Niklas NelsonAm 18.08.2023 20:18 schrieb Taylor C Jensen @.***>: Did you do any kind of docker updates or system updates or a reboot or anything? I'm not sure what causes it, but I've also lost my data again. I had some snapshots and went back in time far enough that I could boot, exported the database, when back to the present, and just imported the database back in. But obviously this is extremely cumbersome and should be unnecessary.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

hack0X0 commented 9 months ago

I can report the same issue, after setting up all information and working for a while, suddenly its stopped working.

Somehow all the tables are being deleted on docker.

weasam commented 9 months ago

Dolibarr 18.0.3 PHP7.4-FPM

Would it be the PHP version make this error? PHP coding bug? ', I tested both php7.4& php8.1both are resulting the same'

I take a over night to test it, it nothing relate to charset. is the module issue neither nothing relate to php version, I did all the test, now is expert to look at these two module codes

When I enable module “PARTNERSHIP MANAGEMENT” could not create customer/vendor/ When I enable module “STOCKS” could not open [Products > Inventory]

but when I disabled these two modules, everything looks fine

Vaadasch commented 4 months ago

Hi, Dolibarr can do a lot of things, but deleting all the tables of its database seems a little too much for it. Not only the optional modules tables but the core tables too, i don't think there is any function to do something like this, let alone the need.

Can you insure that it is not a problem from your database, a corruption of the filesystem or a snapshot that freezing the FS at the wrong time, or whatever reason MariaDB could be resetting itself ?

Or maybe even a bug of this version that crashing because a bad formated SQL string ? That would be the problem of MariaDB, not Dolibarr : even if Dolibarr emit a bad request, that should not make MariaDB drop all its data.

jeff-techstension commented 4 months ago

Dollibar shouldn't be doing anything to drop all the tables. However, if the compose files owns the volumes then it is very easy to lose the database due to something like docker compose down -v.

I would suggest replacing the volume holding the database files, mysql-data, with an external volume outside of the compose file. You can either create it directly with docker or use a real directory.

After a few misadventures of my own this is the ruleset I use.

  1. Compose volumes when the application can recreate it if it's missing. I.E Caching
  2. External docker volumes when the data is important but I don't care where it is stored usually. I.E image uploads/documents
  3. Real Directories if I need to know where the data is stored. I.E Databases

2 or 3 are fairly interchangeable in general but 3 also gives you the ability to add things to the volume being mounted to the volume which comes in handy for databases.