Redmine

A 500 Internal Server Error in Redmine, especially when installing or updating plugins, is a common issue. The fact that it's occurring with both the Redmine Contacts and Redmine DMSF plugins suggests a systemic problem rather than a bug with a single plugin. Since you're running Redmine in a Docker environment, the issue could be related to file permissions, a failed database migration, or a conflict between plugins. The absence of logs is also a key symptom that points to a specific set of potential causes.

Here's a breakdown of the likely causes and troubleshooting steps, starting with the most probable:

1. File Permissions
This is the most common reason for a 500 error, particularly when no logs are generated. If the web server (e.g., Apache or Nginx) and the Redmine application cannot write to the log directory, it can't record the error, resulting in a generic 500 page.

How it happens: Docker containers often run as a specific user (e.g., www-data or redmine). If you installed the plugins or ran commands as a different user (e.g., root), the new files and directories might have incorrect ownership or permissions.

What to do:

Find the Redmine log directory, which is usually redmine/log.

Change the ownership of the Redmine installation directory to the user running the Redmine process in the container. The command would look something like chown -R <user>:<group> /path/to/redmine. You'll need to figure out the correct user and group from your Docker image's configuration. A common one is www-data:www-data.

After correcting permissions, a new production.log should be created (or the existing one will be written to) when you try to access the plugin page again.

2. Failed Database Migration
After installing or updating a plugin, it's crucial to run database migrations. If a migration fails, it can leave the database in an inconsistent state, causing a 500 error.

How it happens: The rake redmine:plugins:migrate command (or bundle exec rake redmine:plugins:migrate for newer Redmine versions) is essential. If it wasn't run correctly, or if there was an error during the process, the database tables required by the new plugin won't exist or won't be configured correctly.

What to do:

Access the Redmine Docker container's command line.

Run the migration command again, making sure to specify the production environment: RAILS_ENV=production bundle exec rake redmine:plugins:migrate.

If there's an error during the migration, the output will tell you what went wrong. This is a critical step for getting more specific information.

You can also try running the migration for just the specific plugin that's causing issues.

3. Plugin Conflicts or Incompatibility
Redmine plugins, especially from third-party developers, can sometimes conflict with each other or with the core Redmine version. Your current environment has a number of plugins, which increases the chance of a conflict.

How it happens: Two plugins might try to modify the same Redmine core file or database table, or they might rely on different versions of the same dependencies.

What to do:

Try to isolate the problem. Disable all plugins except for the one you're trying to install (redmine_contacts) and the ones you can't remove (like the DMSF plugin that also gave you issues).

Start Redmine and see if the error persists. If it's gone, re-enable your other plugins one by one to find the culprit.

Check the Redmine Contacts plugin's compatibility with your specific Redmine version (4.2.3). While RedmineUP usually provides this information, double-checking is a good practice. Also, verify the version of the DMSF plugin is compatible with Redmine 4.2.3.

4. Docker-Specific Issues
Docker adds a layer of complexity. Misconfiguration of the container itself can lead to problems.

How it happens: The way volumes are mounted, or how the application is started, can affect file permissions and access to other resources.

What to do:

Review your Dockerfile or docker-compose.yml file. Ensure that the volumes for plugins and logs are correctly mapped and that the container is running with the correct user.

Restart the Redmine container after making any changes.

A General Troubleshooting Workflow
Correct Permissions: This is the first thing to check. Find the Redmine log directory and make sure the user running Redmine has write access. If there are still no logs, check the web server logs (e.g., Apache or Nginx) on the host system, as the error might be occurring before Redmine can even start up.

Run Migrations: Execute the database migration command with RAILS_ENV=production. This is a non-destructive action that should solve most plugin-related database issues.

Check for Conflicts: If the error persists, disable all third-party plugins. Start with a clean slate and add them back one by one.

Check Plugin Version: Ensure the plugin version is explicitly compatible with Redmine 4.2.3.

Thank you, we did all this, problems arise at the "db magration" stage, most likely some problem in our database prevents migration, but since there are no logs of this process, it is impossible to understand what exactly prevents it.