Status 500 "Error calling /en/." since 1.16.0

[Kabelkrant]

Describe the bug Since upgrading to 1.16.0, almost every page displays an error 500. It states:

error (Status 500) Error calling /en/. Try to reload the page or contact the administrator if this error persists.

To Reproduce Steps to reproduce the behavior:

1. On Synology Docker, run jbtronics/part-db1 version 1.15.2
2. Upgrade docker image to 1.16.0
3. Run php bin/console doctrine:migrations:migrate as user www-data, type Yes, migation succesful
4. Visit part-db in the browser and login
5. Error pops up

The error message advises to run php bin/console cache:clear but this does not help.

Screenshots https://postimg.cc/4YYQJtnW

Server Side Host 10.0.20.2

• Synology DSM 7.2.2 docker
• jbtronics/part-db1:latest (port mapping 8091:80, see docker-compose below)

Host 10.0.20.4

• Ubuntu
• NGINX reverse proxy listening to host https://stuff.home.kabelkrant.net, forwarding to http://10.0.20.2:8091
• 11.4.4-MariaDB-ubu2404 - mariadb.org binary distribution

Desktop:

• Windows 10, Firefox 135

Additional context My docker-compose is:

version: '3.3'
services:
  partdb:
    container_name: partdb
    ports:
      - '8091:80'
    volumes:
      - /volume1/docker/partdb/uploads:/var/www/html/uploads
      - /volume1/docker/partdb/public_media:/var/www/html/public/media
      - /volume1/docker/partdb/db:/var/www/html/var/db
    restart: unless-stopped
    image: jbtronics/part-db1:latest
    environment:
      - DATABASE_URL=mysql://stuff:(password)@10.0.20.4:3306/stuff
      - APP_ENV=docker
      - DEFAULT_LANG=en
      - DEFAULT_TIMEZONE=Europe/Amsterdam
      - BASE_CURRENCY=EUR
      - INSTANCE_NAME=Kabelkrant Inventaris
      - ALLOW_ATTACHMENT_DOWNLOADS=0
      - USE_GRAVATAR=0
      - DEFAULT_URI=https://stuff.home.kabelkrant.net
      - TRUSTED_PROXIES=10.0.20.0/16
      - BANNER=Welkom!

[jbtronics]

What do the logs of Part-DB says? It will explain what the 500 error means

[Kabelkrant]

I couldn't access the logs, as the logs are maybe inside the docker container instead of a mounted folder? I could however capture the STDOUT of the docker container.

Please see the attached file (it's HTML). It starts at the bottom going up.

partdb_session.txt

Edit: This line:

[previous exception] [object] (PDOException(code: 42S22): SQLSTATE[42S22]: Column not found: 1054 Unknown column 't0.internal_path' in 'SELECT' at /var/www/html/vendor/doctrine/dbal/src/Driver/PDO/Statement.php:55)

[tpazdera]

Same exact issue.....

• Environment - Docker container on Synology Diskstation
• Upgraded to Part-DB 1.16.0
• Ran command to upgrade database

root@DiskStation:~# docker exec -it c340ad8728f8 bash
root@70e8d56cb8ea:/var/www/html# 
root@70e8d56cb8ea:/var/www/html# sudo -H -u www-data bash -c 'php bin/console doctrine:migrations:migrate'

 WARNING! You are about to execute a migration in database "main" that could result in schema changes and data loss. Are you sure you wish to continue? (yes/no) [yes]:
 > yes

[notice] Migrating up to DoctrineMigrations\Version20250222165240
[warning] Migration not needed for SQLite. Skipping...
[warning] Migration DoctrineMigrations\Version1 was executed but did not result in any SQL statements.
[warning] Migration not needed for SQLite. Skipping...
[warning] Migration DoctrineMigrations\Version20190902140506 was executed but did not result in any SQL statements.
[warning] Migration not needed for SQLite. Skipping...
[warning] Migration DoctrineMigrations\Version20190913141126 was executed but did not result in any SQL statements.
[warning] Migration not needed for SQLite. Skipping...
[warning] Migration DoctrineMigrations\Version20190924113252 was executed but did not result in any SQL statements.
[warning] Migration not needed for SQLite. Skipping...
[warning] Migration DoctrineMigrations\Version20191214153125 was executed but did not result in any SQL statements.
[warning] Migration not needed for SQLite. Skipping...
[warning] Migration DoctrineMigrations\Version20200126191823 was executed but did not result in any SQL statements.
[warning] Migration not needed for SQLite. Skipping...
[warning] Migration DoctrineMigrations\Version20200311204104 was executed but did not result in any SQL statements.
[warning] Migration not needed for SQLite. Skipping...
[warning] Migration DoctrineMigrations\Version20200409130946 was executed but did not result in any SQL statements.
[warning] 
[warning] The initial password for the "admin" user is: 1e3c5ea937
[warning] 
[warning] Migration DoctrineMigrations\Version20230417211732 was executed but did not result in any SQL statements.
[warning] Migration DoctrineMigrations\Version20240728145604 was executed but did not result in any SQL statements.
[notice] finished in 1599.4ms, used 36.5M memory, 32 migrations executed, 1067 sql queries
                                                                                                                        
 [OK] Successfully migrated to version: DoctrineMigrations\Version20250222165240

• Received Internal Server Error 500 errors
• Most sections of Part-DB are now inaccessible
• Tried to clear cache as a potential fix to no avail.

root@70e8d56cb8ea:/var/www/html# sudo -H -u www-data bash -c 'php bin/console cache:clear'                

 // Clearing the cache for the prod environment with debug false                                                        
                                                                                                                        
 [OK] Cache for the "prod" environment (debug=false) was successfully cleared.        

Found line in error log which indicates a database schema problem.. [previous exception] [object] (PDOException(code: 42S22): SQLSTATE[42S22]: Column not found: 1054 Unknown column 't0.internal_path' in 'field list' at /var/www/html/vendor/doctrine/dbal/src/Driver/PDO/Statement.php:55)

[jbtronics]

In both cases it appears, that he cant find the internal_path column for the attachments. This one was introduced with the changed attachment system and should be created by the database migration.

You should check if that the database attachments table contain an internal_path and external_path and no path column.

In my private instance and the demo instance the new Part-DB and the required migration works fine...

[Kabelkrant]

The migration script told me it was succesful, just like tpazdera but indeed in my attachments table I only have the path column.

[kilrah]

Same problem

[previous exception] [object] (Doctrine\\DBAL\\Driver\\PDO\\Exception(code: 1): SQLSTATE[HY000]: General error: 1 no such column: t0.internal_path at /var/www/html/vendor/doctrine/dbal/src/Driver/PDO/Exception.php:24)

I saw there were migrations to perform, did so and cleared cache but no change and the column isn't there.

Using the Docker container on Unraid with sqlite.

[sergeyyarkov]

I'm just trying to copy the app.db file from version 1.14.5 to version 1.16.0 and I can't because the attachments table doesn't have internal_path and external_path columns. How can I export the database? I tried to export to json format in the web interface, but my pictures and documents are not loaded when imported and I get a 404 error. Perhaps this is due to a path conflict in url???? on the old version the path to the file looks like this: /media/part/datasheet.pdf but in the new version the response is 302 and in the end I get 404 =(((((

[kilrah]

Edit: Now see that this was in the mySQL function and the sqlite one was more elaborate... but it worked anyway as far as I can tell. Probably don't do that in your setup.

From what I can see it chokes on

//Create the new columns as nullable (that is easier modifying them)
        $this->addSql('ALTER TABLE attachments ADD internal_path VARCHAR(255) DEFAULT NULL, ADD external_path VARCHAR(255) DEFAULT NULL');

not liking the 2 statements in one, threw an error in my sqlite editor, I ran the whole block manually with that as 2 separate statements and it worked.

ALTER TABLE attachments ADD internal_path VARCHAR(255) DEFAULT NULL;  
ALTER TABLE attachments ADD external_path VARCHAR(255) DEFAULT NULL;
UPDATE attachments SET external_path=path;
ALTER TABLE attachments DROP path;
UPDATE attachments SET internal_path=external_path WHERE external_path LIKE "#%MEDIA#%%" ESCAPE "#";
UPDATE attachments SET internal_path=external_path WHERE external_path LIKE "#%BASE#%%" ESCAPE "#";
UPDATE attachments SET internal_path=external_path WHERE external_path LIKE "#%SECURE#%%" ESCAPE "#";
UPDATE attachments SET internal_path=external_path WHERE external_path LIKE "#%FOOTPRINTS#%%" ESCAPE "#";
UPDATE attachments SET internal_path=external_path WHERE external_path LIKE "#%FOOTPRINTS3D#%%" ESCAPE "#";
UPDATE attachments SET internal_path=external_path WHERE external_path LIKE "#%FOOTPRINTS3D#%%" ESCAPE "#";
UPDATE attachments SET external_path=NULL WHERE internal_path IS NOT NULL;

[jbtronics]

What does php .\bin\console doctrine:migration:list output? The DoctrineMigrations\Version20250220215048 should have migrated status.

[tpazdera]

In my case I show that that version does have a migrated status.

| DoctrineMigrations\Version20250220215048 | migrated | 2025-02-24 12:35:54 | 0.003s | Split $path property for attachments into $internal_path and $external_path

[jbtronics]

I have slightly changed the migration (into basically what @kilrah) reported as succesful. For MySQL this is bascially the same as before, for sqlite its slightly different, but this should normally not make a difference.

You can either take the latest commit from the repo master branch, or you wait until the docker image is built, and use the jbtronics/part-db1:master image, and try it out if it is working that way...

[partywagon112]

I'm unsure if this is the same issue, as I was only encountering Error 500 past /en/ pages where the database was referenced. This previous thread helped https://github.com/Part-DB/Part-DB-server/discussions/648.

[Kabelkrant]

The problem persists in jbtronics/part-db1 version 1.16.1

I updated the docker image from 1.16.0 to 1.16.1

After the update I did the migration:

root@d974f80076a4:/var/www/html# sudo -u www-data php bin/console doctrine:migrat
ions:migrate                                                                     
                                                                                 
 WARNING! You are about to execute a migration in database "main" that could resu
lt in schema changes and data loss. Are you sure you wish to continue? (yes/no) [
yes]:                                                                            
 > yes                                                                           
                                                                                 
[notice] Migrating up to DoctrineMigrations\Version20250222165240                
[warning] Migration not needed for SQLite. Skipping...                           
[warning] Migration DoctrineMigrations\Version1 was executed but did not result i
n any SQL statements.                                                            
[warning] Migration not needed for SQLite. Skipping...                           
[warning] Migration DoctrineMigrations\Version20190902140506 was executed but did
 not result in any SQL statements.                                               
[warning] Migration not needed for SQLite. Skipping...                           
[warning] Migration DoctrineMigrations\Version20190913141126 was executed but did
 not result in any SQL statements.                                               
[warning] Migration not needed for SQLite. Skipping...                           
[warning] Migration DoctrineMigrations\Version20190924113252 was executed but did
 not result in any SQL statements.                                               
[warning] Migration not needed for SQLite. Skipping...                           
[warning] Migration DoctrineMigrations\Version20191214153125 was executed but did
 not result in any SQL statements.                                               
[warning] Migration not needed for SQLite. Skipping...                           
[warning] Migration DoctrineMigrations\Version20200126191823 was executed but did
 not result in any SQL statements.                                               
[warning] Migration not needed for SQLite. Skipping...                           
[warning] Migration DoctrineMigrations\Version20191214153125 was executed but did
 not result in any SQL statements.                                               
[warning] Migration not needed for SQLite. Skipping...                           
[warning] Migration DoctrineMigrations\Version20200126191823 was executed but did
 not result in any SQL statements.                                               
[warning] Migration not needed for SQLite. Skipping...                           
[warning] Migration DoctrineMigrations\Version20200311204104 was executed but did
 not result in any SQL statements.                                               
[warning] Migration not needed for SQLite. Skipping...                           
[warning] Migration DoctrineMigrations\Version20200409130946 was executed but did
 not result in any SQL statements.                                               
[warning]                                                                        
[warning] The initial password for the "admin" user is: _(password, redacted)_          
[warning]                                                                        
[warning] Migration DoctrineMigrations\Version20230417211732 was executed but did
 not result in any SQL statements.                                               
[warning] Migration DoctrineMigrations\Version20240728145604 was executed but did
 not result in any SQL statements.                                               
[notice] finished in 1371.6ms, used 36.5M memory, 32 migrations executed, 1060 sq
l queries                                                                        
                                                                                 
 [OK] Successfully migrated to version: DoctrineMigrations\Version20250222165240

After that, I logged back in to part-DB. The home page works and confirms i'm on 1.16.1, but give the same popup:

error (Status 500) Error calling /en/. Try to reload the page or contact the administrator if this error persists.

Every other page directly displays error 500.

The logs show this line:

[previous exception] [object] (PDOException(code: 42S22): SQLSTATE[42S22]: Column not found: 1054 Unknown column 't0.internal_path' in 'SELECT' at /var/www/html/vendor/doctrine/dbal/src/Driver/PDO/Statement.php:55)

Here is my full log (again HTML going bottom to top)

250226_partdb.txt

Do you need anything else?

[tpazdera]

I have the same issue. I upgraded to 1.16.1, re-ran the doctrine:migrate command. The messages claimed that the task was either not needed or no task "was executed but did not result in any SQL statements." However, all migration tasks completed successfully, confirmed by doctrine:list.

root@0f5fb4e2c62a:/var/www/html# sudo -H -u www-data bash -c 'php bin/console doctrine:migrations:list' | grep path
| DoctrineMigrations\Version20250220215048 | migrated | 2025-02-27 03:18:51 | 0.018s         | Split $path property for attachments into $internal_path and $external_path 

The attachments table still contains the old path...

MySQL [partdb]> desc attachments;
+-------------------+--------------+------+-----+-------------------+-------------------+
| Field             | Type         | Null | Key | Default           | Extra             |
+-------------------+--------------+------+-----+-------------------+-------------------+
| id                | int          | NO   | PRI | NULL              | auto_increment    |
| type_id           | int          | NO   | MUL | NULL              |                   |
| element_id        | int          | NO   | MUL | NULL              |                   |
| show_in_table     | tinyint(1)   | NO   |     | NULL              |                   |
| path              | varchar(255) | NO   |     | NULL              |                   |
| name              | varchar(255) | NO   | MUL | NULL              |                   |
| last_modified     | datetime     | NO   |     | CURRENT_TIMESTAMP | DEFAULT_GENERATED |
| datetime_added    | datetime     | NO   |     | CURRENT_TIMESTAMP | DEFAULT_GENERATED |
| class_name        | varchar(255) | NO   | MUL | NULL              |                   |
| original_filename | varchar(255) | YES  |     | NULL              |                   |
+-------------------+--------------+------+-----+-------------------+-------------------+
10 rows in set (0.003 sec)

Anything I am doing wrong?

[salvatoreraccardi]

Hi, I have the same issue.

If I try to add a new part it does not work, only the categories, projects and basic information are saved correctly in the db.

MariaDB [partdb]> desc attachments;
+-------------------+--------------+------+-----+---------------------+----------------+
| Field             | Type         | Null | Key | Default             | Extra          |
+-------------------+--------------+------+-----+---------------------+----------------+
| id                | int(11)      | NO   | PRI | NULL                | auto_increment |
| type_id           | int(11)      | NO   | MUL | NULL                |                |
| element_id        | int(11)      | NO   | MUL | NULL                |                |
| show_in_table     | tinyint(1)   | NO   |     | NULL                |                |
| name              | varchar(255) | NO   | MUL | NULL                |                |
| last_modified     | datetime     | NO   |     | current_timestamp() |                |
| datetime_added    | datetime     | NO   |     | current_timestamp() |                |
| class_name        | varchar(255) | NO   | MUL | NULL                |                |
| original_filename | varchar(255) | YES  |     | NULL                |                |
| internal_path     | varchar(255) | YES  |     | NULL                |                |
| external_path     | varchar(255) | YES  |     | NULL                |                |
+-------------------+--------------+------+-----+---------------------+----------------+
11 rows in set (0.002 sec)

[kilrah]

The problem persists in jbtronics/part-db1 version 1.16.1

Same, I restored an old DB and tried upgrading it with the :master tag and it also did not work

[tpazdera]

@salvatoreraccardi It looks like you may have a different problem. This issue is specifically for the database issue where the attachments table has not been migrated to a later schema. My table has a "path" column, but yours has the updated "internal_path", "external_path".

There may be a new thing going on. You may have to check your logs and perhaps start a new issue.

[salvatoreraccardi]

@tpazdera You are right, I noticed it now thanks for the feedback. I did a fresh install and encountered the problem I reported in the comment above right away. I don't understand what I'm doing wrong.

[tpazdera]

I manually ran the update steps from @kilrah above, everything works fine for me now.

[iceyman]

upgrading from 1.14.2 to 1.16.2 and i get

[jbtronics]

upgrading from 1.14.2 to 1.16.2 and i get

Have you tried to upgrade before? What database server are you running?

[jbtronics]

@tpazdera @Kabelkrant I think your problem is that with the way you are calling the database migration, you are applying the migrations to the wrong kind of database, as your sudo command there doesn't pass the env variables with the database path to the migration command. So instead of using your configured mysql database, it migrates on the default sqlite database (as defined in .env file). That's why you see the "not needed for sqlite" and it is applying the migrations from version1 onwards, as this sqlite database is empty.

To properly perform the database migration, call the migration via docker exec --user=www-data partdb php bin/console doctrine:migrations:migrate like documented here or open a console directly as the www-data user. If you want to use sudo you can probably use the -E flag to preserve the env vars, when running under a different user.

[iceyman]

upgrading from 1.14.2 to 1.16.2 and i get

Have you tried to upgrade before? What database server are you running?

Yes i have upgraded this before and haven't had an issue until now, it's ok looks like the DB has been wiped so i'll try a freash install on bullseye and re install partsDB and see what happens

[Kabelkrant]

Can’t the docker not automigrate when it senses the database is out of date during startup of the container?

In my experience it’s common practice in the selfhosted space, at least I know Jellyfin and Bookstack do it this way.

The thing is, we run Docker through an GUI frontend (Synology Container Manager) and don’t interact directly with the Docker CLI.

We might be able to, but it’s advised against to to SSH directly into a NAS operating system.

I would totaly understand if we’re not your target audience, but I love running this at home.

[MVM6508]

I'm not sure if this is the same issue but I run in to trouble updating my docker install from 1.15 to 1.16.

When trying to migrate the database with: sudo docker exec --user=www-data partdb php bin/console doctrine:migrations:migrate I got: General error: 1419 You do not have the SUPER privilege and binary logging is enabled (you might want to use the less safe log_bin
trust_function_creators variable) _

I solved it with adding "command: ["--log_bin_trust_function_creators=1"]" to my docker-compose.yml

However I'm not sure if it's the right way to do it?

[jbtronics]

I solved it with adding "command: ["--log_bin_trust_function_creators=1"]" to my docker-compose.yml

However I'm not sure if it's the right way to do it?

@MVM6508 That is actually a different probel. But the solution is fine (and is actually documented that way). Thats an restriction of MySQL with stored functions, which should prevent certain security issues when using replicated databases. But especially in the case, when MySQL is running in a docker container and only Part-DB is accessing it, there is nothing unsafe about it.

The alternative would be to disable this option via an "SET GLOBAL" option.

[jbtronics]

@Kabelkrant

Can’t the docker not automigrate when it senses the database is out of date during startup of the container?

Calling the migrating script at container startup is not difficult, and the frankenphp based image partdborg/part-db actually does that (https://github.com/Part-DB/Part-DB-server/blob/master/.docker/frankenphp/docker-entrypoint.sh)

However there is a certain risk, because if the database migration should fail for whatever reason, the database might end up in some state in between migrations, that are difficult to recover from automatically. And if the user has no backup it can be difficult to recover from that. You might able to automatically backup the database before approaching migration, but that complicates things a bit more...

[sochartgit]

Gosh, same problem here, about every 2 versions, I get those bloody errors. That's really annoying. Migration done, containers restarted but the error is still there.

Same exact thing:

[jbtronics]

@sochartgit That is most likely the same problem as above. You must run the migrations with sudo docker exec --user=www-data partdb php bin/console doctrine:migrations:migrate, or if you want to to use the sudo command inside the docker container, you must use sudo -E. Otherwise the console command does not see the env variables containing the database path, and applies the migrations to the wrong database...

[Protoncek]

Hello guys! How to migrate if partDB is installed in Proxmox? If i go in console and enter "php bin/console doctrine:migrations:migrate" i get an error "could not open file: bin/console". My installation is unprivileged, which means i can't connect with putty. What am i doing wrong? Otherwise, web page works, i also have all my inventory, so it seems that all works... does that means that i don't have to migrate?