search

espocrm / espocrm-docker

Official Docker Image for EspoCRM
https://hub.docker.com/r/espocrm/espocrm
GNU Affero General Public License v3.0
56 stars 34 forks source link

Error in folder permissions in Docker configuration #49

Closed andrewvaughan closed 2 weeks ago

andrewvaughan commented 2 weeks ago

Describe the bug When setting EspoCRM up via Docker, and trying to create a new Entity, a 500 Error is returned with the following in the logs:

[2024-06-18 22:11:45] WARNING: E_WARNING: mkdir(): Permission denied {"code":2,"message":"mkdir(): Permission denied","file":"/var/www/html/application/Espo/Core/Utils/File/Manager.php","line":561}
[2024-06-18 22:11:45] WARNING: E_WARNING: mkdir(): No such file or directory {"code":2,"message":"mkdir(): No such file or directory","file":"/var/www/html/application/Espo/Core/Utils/File/Manager.php","line":561}
[2024-06-18 22:11:45] ERROR: (0) Permission denied: unable to create a folder on the server custom/Espo/Custom/Resources/i18n/en_US; POST /EntityManager/action/createEntity; line: 700, file: /var/www/html/application/Espo/Core/Utils/File/Manager.php

The Entity will not appear in the list, but trying to create another Entity of the same name will create a 409 error similar to:

[2024-06-18 22:11:47] ERROR: (409) Name 'CService' is already used.; POST /EntityManager/action/createEntity; line: 61, file: /var/www/html/application/Espo/Core/Exceptions/Conflict.php

To Reproduce (MANDATORY, DO NOT REMOVE) Explicit steps to reproduce the behavior:

  1. Create EspoCRM through Docker
  2. Attempt to create a new Entity

Expected behavior The Docker container should have its directory permissions configured appropriately as part of the build. As of right now, the volume permissions need to be manually changed after the Docker container is created and the volume is populated.

Screenshots N/A

EspoCRM version Whatever the version is just-prior to the 8.2.5 update - presumably 8.2.4.

Note - please put your version in your footer or on the Administration page. As I type this I don't know where to go to find the version, as I'm using the latest tag for my container.

Additional context It seems that EspoCRM creates the database entry even though the system threw an error - this is bad transaction practice. The entire database entry should be wrapped in a transaction and rolled back if an error like this occurs.

Right now, my system is in a state where I can't create the Entities I need, because the database records exist, but the failure to update the filesystem (whatever it was) causes it to not appear in my administration.

Any advice on how I can repair my existing setup would be appreciated. I can delete records in the database, I just need to know which ones and if they appropriately cascade to any foreign records.

yurikuzn commented 2 weeks ago

It seems that EspoCRM creates the database entry even though the system threw an error - this is bad transaction practice.

Database is created from a schema which is defined in metadata. When you create an entity, it creates an additional metadata files. If the same name is already used, it won't create metadata, it won't create anything.

Likely you have metadata created but problems with cache due file permissions. Database transactions are not relevant here. Database too.

yurikuzn commented 2 weeks ago

You can find your entity files here and delete them manually.

andrewvaughan commented 2 weeks ago

@yurikuzn please re-read my report. The problem is, the EspoCRM Dockerfile is missing a step that properly sets folder permissions. The Entity files were never created, so I have database entries (or possibly cache?) but not files. Regardless, the Dockerfile or its entrypoint needs to appropriately set directory permissions on an initial install.

Right now I'm getting this error whenever I try to recreate the service, which tells me the Database thinks the Entity exists, but the files were never created:

[2024-06-18 22:11:47] ERROR: (409) Name 'CService' is already used.; POST /EntityManager/action/createEntity; line: 61, file: /var/www/html/application/Espo/Core/Exceptions/Conflict.php
arkadiyasuratov commented 2 weeks ago

Docker works well on our servers. To fix file permissions, just use chown inside a container. If you're using a bind mount, make sure the right user is set because Docker uses www-data.

yurikuzn commented 2 weeks ago

As you asked advice how you can repair, I suggested to remove files manually.

I'm not resosible for docker setup, but I believe we have many users without this issue.

Database has nothing to do here. You need to fix file permussions or ownership and run rebuild.

andrewvaughan commented 2 weeks ago

@arkadiyasuratov I was also able to confirm with a fresh install that this isn't an issue. Also, updating to the latest version seemed to fix the ghost in the machine, and nothing in the most recent update's diff looks related to permission changes, so it's a very odd situation.

The only entities that have access to my Docker volume on the server are the espocrm containers (primary app and daemon) so I'm not certain how file permission issue could even present.

Edit: Looking closer at the upgrade - it looks like there's logic to update these permissions on upgrade, which likely fixed my issue. It doesn't explain why my directories didn't have the correct permissions set in the first place (again, I'm the only dev and the only thing that has modified this directory are the EspoCRM containers themselves) but the upgrade resolved the problem.

I was able to resolve my issue simply by upgrading.

If anyone finds this thread in the future with a similar issue, please (a) leave a comment or open your own issue with more details, so the team can identify if they have a ghost in the machine bug, and (b) do this to fix your system:

  1. Enter your container with:
docker exec -it espocrm bash

  1. Set the volume directory permissions per the directions here

  2. Rebuild your database

@yurikuzn I appreciate your attempt to help repair. In my case - the errors pretty clearly said the problem was it couldn't make any files in those folders due to permission errors, so there's seemingly nothing to remove, unless I'm misunderstanding your instructions.

I am still gettin the Error 409: Name 'CService' is already used., even though my file permission issues seem to be resolved, leading me to think that a database lookup was causing the 409 error.

However, rebuilding the database did seem to fix the issue, so I appreciate your guidance on that.

I will close this issue - thanks all.

andrewvaughan commented 2 weeks ago

Followup for anyone looking for a resolution here:

Also delete these files (for each erroring type) as per @yurikuzn. In my case per a new Service Entity:

I did not find any related files in /var/www/html/custom/Espo/Custom/Resources/metadata.