V. latest / 1.6.0

[leandro-effinger]

• I'm submitting a ...
  • [x] bug report
  • [ ] feature request

I was trying to initialize the invoiceplane docker as a compose. After the language selection I get the following error. Can you help me out with that?

I tryed it with the latest and the v1.6.0

For better understanding is hear a part of my compose file too:

  invoiceplane:
    container_name: invoiceplane
    image: mhzawadi/invoiceplane:latest
    volumes:
      - /var/docker/config/invoiceplane/app:/var/www/html/uploads
    environment:
      - TZ=Europe/Berlin
      - MYSQL_HOST=mariadb_10_4
      - MYSQL_USER=InvoicePlane
      - MYSQL_PASSWORD=changeme
      - MYSQL_DB=InvoicePlane
      - IP_URL=http://invoiceplane.domain.de
      - DISABLE_SETUP=false
    restart: unless-stopped
    depends_on:
      - postgres

  mariadb_10_4:
    container_name: ip_mariadb
    # MySQL 5.7
    image: mariadb:10.4.10
    volumes:
      - /var/docker/config/invoiceplane/mariadb:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=changeme
      - MYSQL_DATABASE=invoiceplane
      - MYSQL_USER=invoiceplane
      - MYSQL_PASSWORD=changeme
    restart: unless-stopped

---

I was the guy who published the bug with the broken PDF generator. https://github.com/mhzawadi/invoiceplane/issues/31

I was trying to complete re initialize the the docker compose on a clean system and got this new bug.

thanks in advance.

[leandro-effinger]

sry, for the little mistake on depends_on. I know that is mariadb and not postgres. pls. ignore it.

[mhzawadi]

Hey @leandro-effinger

That looks like your container is missing the needed permissions to write to the upload directory, could check that?

[powellcn]

I encountered the same issue while installing. I manually created the directories and manually set the permissions to match. I also used compose (on Portainer) and created the volume the same way shown above.

[jvoshage]

I ran into this problem as well yesterday. I was able to fix it by setting all the failed folder permissions to rwxr-xrwx (chmod 757). I am not sure if this is the proper way to do it but it worked for me.

[nielsdrost7]

The title of this issue should be something describing that you don't have the proper rights to write to the /uploads directory.

In Dockerfile#L9C33-L9C33 the directory uploads is created. In Dockerfile#L33 the owner of that directory is set to nobody:nginx. But there's also a volume created to that directory (from the host system). I think those 3 things are conflicting. If you log into the container (docker-compose exec -it invoiceplane /bin/bash) and do an ll /var/www/html/ you'll see who owns that uploads directory (and who owns the rest).

It might just be simple write permissions on that uploads directory, that's causing this problem.

[mhzawadi]

Hello @leandro-effinger

A quick look at the owner IDs in the container shows the owners should be 65534 and 100, the command chown 65534:100 /var/docker/config/invoiceplane/app on the host should work. the ID 65534 should have rwx on that directory too

[the-hotmann]

65534 and 100

Sorry this is not right. Had a look myself - must be: 65534 and 101.

U_ID: 65534 (nobody) G_ID: 101 (nginx)

Please add this to the docs. Or even better, since this container is running on as root. The container itself can run this command on startup:

chown -R 65534:101 /var/www/html/

Also everyone who wants to run this as a docker, wants these folders/files to be persistent:

1. uploads/
2. application/
3. ipconfig.php (file)

After you completet #39 ipconfig.php does not have to be persistent anymore, as it is completely set by the new SED script which covers 100% of all variables which are to be set.

Like I said, I think the folders mentioned above shall be persistent. therefor you normally map a folder from the host to the container - something like this:

volumes:
      - "/var/docker/config/invoiceplane/uploads/:/var/www/html/uploads/:rw"
      - "/var/docker/config/invoiceplane/logs/:/var/www/html/application/logs/:rw"
      - "/var/docker/config/invoiceplane/ipconfig.php:/var/www/html/ipconfig.php:rw"

But like I said, the way this Image is made, this is not intended.

(docker-compose exec -it invoiceplane /bin/bash)

Shall be docker exec -it invoiceplane sh in this case here, as the author did not include bash.

But the direction is correct.

In Dockerfile#L9C33-L9C33 the directory uploads is created. In Dockerfile#L33 the owner of that directory is set to nobody:nginx.

This is where I think the problem lays. This shall be done on Build time, but also on container start, because when someone does make some folder persistent, it must be done again.

This requires a script that does these two things:

1. check if folder exists and if not, creates them
2. set permission recursively for all folders neccecary
3. maybe also set/check permission.

This issue is completely the fault of the issue-creator, but yet things are not as a normal docker-user would expect them if he wants his data to be persistent. Also keep in mind that the docs here do not state which folders, shall be persistent. Also I think you can close this issue by now.

[the-hotmann]

Here how the script could look like:

[[ ! -d "/var/www/html/uploads/temp/mpdf/" ]] && mkdir -p "/var/www/html/uploads/temp/mpdf/"
[[ ! -d "/var/www/html/uploads/customer_files/" ]] && mkdir -p "/var/www/html/uploads/customer_files/"
[[ ! -d "/var/www/html/uploads/archive/" ]] && mkdir -p "/var/www/html/uploads/archive/"
[[ ! -d "/var/www/html/application/logs/" ]] && mkdir -p "/var/www/html/application/logs/"

chown -R nobody:nginx /var/www/html/

This basically is all.

• it creates all missing folder.
• it sets the permission recursively

This would even fix those problems that would occure when someone would map in its own volumes with wrong permissions.