2.7.1 update for Docker broken?


I just upgraded a Docker container install… lots of problems but almost working now… except a bunch of files are now 404 missing…

e.g. daterangepicker.css

Very strange. Anyone else getting this?

ok… i don’t get this… seems the docker pull has not updated any of the JS or CSS folders (what else??)… I’m looking inside the container… when I access via the web page it says it updated, shows the new features (e.g vendors, expenses etc) but the page layout is messed up.

I’m not sure, you may want to create an issue on our Docker GitHub project.


OK, so update…
I still can’t explain why the update on the original docker image completed partially.

I created a new container instead pointed to persistent copies of the data.
More gotchas for anyone else trying this:

NOTE - the (hidden) .env file is not located in the nominated persistent data folders
i.e. /var/www/app/public/logo and /var/www/app/storage.

You need to ensure this is copied over or create a volume for it… it’s located in /var/www/app.

If you have copied data out to a persistent volume, you need to ensure that the files in that volume are owned by www-data and not root. The vendor folder is also the wrong ownership. I think that’s an IN issue…

And the debug option is turned on the docker compose yml file so you might want to turn that off first. Otherwise, I it displays a debug bar… how do you turn that off? it’s says false in my .env file??

I have to do this again tomorrow for another client… I may update this again…

Having re-visited this, here’s some clearer instruction for education for those that need it - use at your own risk.

If you have used the Docker image without setting up persistent storage, here’s how you move the data to persistent storage… which is highly recommended for image updates. Ideally the data should be in its own separate persistent container.

Copy existing data from your containers:

  • Stop your running containers
  • create a new folder for a new docker container - install the updated files from here - https://github.com/invoiceninja/dockerfiles
  • create a new file path to store your data (e.g. use a sub-folder of a new Docker instance)
  • use sample commands:
cd data
docker cp invoiceninja_app_1:/var/www/app/.env ./
docker cp invoiceninja_app_1:/var/www/app/public/logo ./
docker cp invoiceninja_db_1:/var/lib/mysql ./
docker cp invoiceninja_app_1:/var/www/app/storage ./

NOTE: the ownership of the mysql files needs to edited as shown:
sudo chown -R 102:105 mysql

Edit your docker-compose.yml to add volumes pointing to the data copied:

    - ./data/logo:/var/www/app/public/logo
    - ./data/storage:/var/www/app/storage
    - ./data/.env:/var/www/app/.env

If you are using JWilder’s Reverse Proxy, take note of the web port from your OLD container AND the virtual host setting


    - 8083
    - VIRTUAL_HOST=invoiceninja.mydomain.com

Copy these settings into the new docker-compose file. This will ensure consistency of URLs… and you can do this many times creating a new copy of the original data if you trouble with image updates etc… be aware once you have the new container working, that will be your live data.

Be careful that indents on your docker-compose.yml match existing or it will fail.

Double check the .yml file. You are now ready to start
If required, update your container images - docker-compose pull
docker-compose up -d

If you test at this stage, you will get a 500 error. You need to fix the file permissions for the persistent data folders from inside the APP container.

docker exec -it invoiceninja_app_1 bash

Use ls -l -a and check the following folder locations.
/var/www/app/public/logo , /var/www/app/storage and /var/www/app/vendor
The .env file should be OK.
change the ownership as follows:
chown -R www-data:www-data <folder-name>

Exit the container bash - Restart the containers
From your container folder,

docker-compose stop
docker-compose start

Your system should work now and be updated with latest code if you did that.

In future, with the persistent data above, you can remove and re-create containers now without data loss which is good for future updates via the following:

docker-compose stop
docker-compose pull
docker-compose rm
docker-compose up -d

Good luck all!

1 Like

Thanks for sharing the info!

Hello inhv,

.env is here to define some environnement variable, while you do this you should use docker system for environnement variable, or the docker-compose one, as you can see here for exemple https://github.com/invoiceninja/dockerfiles/blob/master/exemple/docker-compose.yml#L14

For the rest of your topic, it’s a special cas for people who want to retrieve data from an old container, this can be really usefull for some user who want to have a persistent instance after having test it.

Maybe we can add this on the docker repository, maybe not directly on the Readme but in the wiki.
Do you want to make a contribution in this way ?

Hi Samuel/lalop,

As for the Line 14, debug setting, yes, I saw that and changed that for the next one I did, but I’m still unable to turn off debug on the first installation even though it’s off in the .ENV file…?

I’m still learning Docker so not sure if what I’m doing is best practice. I added this info to help others and give myself a reference for next time.

It would help to know in the readme that the .env is important for persistence or moving /copying an installation. You cannot upgrade an installation using your suggested steps (i.e. docker-compose rm) without losing the .env otherwise which breaks the install… you need to keep the .env in persistent storage.


inhv, you havn’t to persist .env since all this information can be into the docker-compose file.

how are yours .env and docker-compose.yml files ?

I had an existing installation with Docker which I needed to update to latest versions. Without knowing that .env existed, the update broke the installation. By copying the old .env file, I was able to get it working.

I only had the vanilla .yml file you provided but added the virtual host and volume info.

Good to know I can add that to the YML file but what happens when an update is made via SETTINGS? You have to manually work out what changed each time , and update the YML when you want to refresh/update the app?

Seems easier to just move .env to persistence? Is there a danger with that?