Closed smacz42 closed 2 years ago
a bug in the entrypoint script (albeit one that wouldn't have manifested itself if you were just using volumes)."
@MohammedAl-Mahdawi is this going to be addressed as the exact issue has been identified? In my use case I prefer to mount exposed volumes on the host for backup and management.
Hi,
This repo is for building the official Akaunting images so please only post issues related to the official Akaunting images or the default setup of the compose files.
If you have questions or issues with your specific setup you can post your question/issue in our support channels here or on StackOverflow.
The given setups/entrypoints are just examples, we don't even recommend using Docker compose in a production environment.
There is no bug or so with the current entrypoints it is just how they work, if you think you can create another setup/entrypoint file in order to show another use case this is a community-driven project please feel free to contribute, and create a pull request, also you can create a feature request which is more than welcome by us and by the community if it will add value to the project.
Thank you for understanding!
Whoever else comes across this error, here is the workaround:
docker create --name akaunting-tmp akaunting/akaunting
docker cp akaunting-tmp:/var/www/html/modules/. ./akaunting_modules
docker rm akaunting-tmp
You can see this workaround in action here: https://gitlab.com/compositionalenterprises/ansible-collection-compositionalenterprises.ourcompose/-/blob/5b5fbf378bce617a5034129eacb5178d439d60e3/roles/akaunting/tasks/running.yml#L38
Here's how a project like Nextcloud does it: https://github.com/nextcloud/docker/blob/master/docker-entrypoint.sh#L93-L112
hello @smacz42 - running into a similar issue and I wonder if it's related: while I was able to get the docker instance up and running using your workaround in the initial setup and subsequent runs, I am now faced with apps not being able to install producing a mkdir() no such file or directory error. The bind mount directory (for "modules") is perfectly write-enabled otherwise - can be tested using docker exec -it akaunting bash. Any suggestions what a workaround might be here? Thank you in advance!
I'm not sure, sorry. I'm honestly surprised to see this type of error if it's writable otherwise. I'd be interested in seeing if you could find a root cause :)
Found the root cause: the app downloads the modules into storage/app/temp/temp-[random string]/* however for some reason the first temp folder was not created in the initial installation. This caused mkdir to fail when trying to make the second temp-[random string] folder. Manually made the first temp folder and everything worked.
Just in case someone also encounters the same issue in the future.
Hi, I have the exact same problem. Same as @MohammedAl-Mahdawi , I tried to follow the official default configuration, and obtained this compose file:
I run this compose with podman-compose like this:
And I end up with this error when the app initializes the database (I think):
Originally posted by @Ezwen in https://github.com/akaunting/docker/issues/38#issuecomment-852084431
The entrypoint should be able to handle this, especially since the recommended way is to mount that directory as a volume.
A lot of what I've seen other container images do is to install the PHP app in
/usr/local/src
, and as the first step in the entrypoint script torsync
the files into the correct directory (/var/www/html
in this case).A workaround for now is to run the container without the volumes (you could also change the entrypoint to simply
bash
if you wanted), copy the files out of the container onto the host, create the bind mount directory manually, copy the files into that directory, then start up the container with the bind mountpoints as volumes. Using something like Ansible to script that simplifies the issue, but ultimately it is a workaround for a bug in the entrypoint script (albeit one that wouldn't have manifested itself if you were just using volumes).