Remove message "you will need to run the following extra step manually"

[luisg123v]

When the --deployv option is used, the following message is shown:

Using --deployv option you will need to run the following extra step manually after to create the container or after running 20-run.sh script
docker exec -it --user=root CONTAINER find /home/odoo -maxdepth 1 -not -user odoo -exec chown -R odoo:odoo {} \;

AFAIK that message is no longer applicable, as the necessary permissions are now run by t2d itself, so the message should be removed.

If the message is still applicable, then I think it should be fixed.

CC @moylop260

[moylop260]

The base Dockerfile has volumes defined for /home/odoo/... sub-folder

• https://git.vauxoo.com/deployv/deployv-static/blob/8346493098af42ee5f4183940b0903624fb03696/deployv_static/templates/base_dockerfile.jinja#L75

It resets the permission if the container is restarted or recently created (even if you had a previuos chown)

You can test it using the following deployv docker image:

docker run -itd --name=test quay.io/vauxoo/vauxoo:vauxoo-16.0-latest
docker exec -it test find /home/odoo -maxdepth 1 -not -user odoo -exec sh -c 'chown -R odoo:odoo "$1" && echo "$1"' _ {} \;

The output is

/home/odoo/.openerp_serverrc
/home/odoo/full_requirements.txt
/home/odoo/.local
/home/odoo/full_test-requirements.txt
/home/odoo/getaddons.py

since that these files have root ownership and it was changed to odoo one

Then, restart the container

docker restart test
sleep 3
docker exec -it test find /home/odoo -maxdepth 1 -not -user odoo -exec sh -c 'chown -R odoo:odoo "$1" && echo "$1"' _ {} \;

The ouput now is

/home/odoo/.openerp_serverrc

Disclaimer: In this point, I was expecting the same output, almost for the ~/.local path that has a volume
Maybe new docker versions avoid changing the ownership for volume after restarting

But even there is a file changed to root

@ruiztulio Do you have any idea where the /home/odoo/.openerp_serverrc is changed to root ownership?

@luisg123v

If after restarting the container the ownership is not changed for /home/odoo paths we could remove this extra step as you said well!

BTW thank you for open the thread

cc @JonathanOsAlc @Angelfentanez

[ruiztulio]

@moylop260 probably when the configuration is updated here, it basically replaces the old file with a new one.

The configuration file shouldn't be on the host machine because it isn't in the volume, the only folders that are mounted from the home are the filestore and ssh (this one is to reduce the risk of pushing a key). So every time you recreate/regenerate the container, it should reset the permissions.

Why is this a problem for the configuration file?

[moylop260]

@luisg123v

After Tulio message it confirms that the message is still needed

Agree?

[luisg123v]

@moylop260,

Antonio faced a similar issue (files marked as volumes) when making authorized keys to work, he fixed it on 001f7f0. What do you think about using a similar approach for this?

[luisg123v]

@ruiztulio,

Answering your question:

Why is this a problem for the configuration file?

The problem is, t2d uses the same customer image as base. But, when using t2d, SSH keys of the current user are copied to the container so that the developer may use them when developing inside the container.

@all,

I'll check this to explore alternatives. For now, I can think of:

1. Running the suggested command in background when running ./12-run.sh
2. Mount a local volume before runnning the docker run command, so that we control its content and permissions
3. Fix permissions in the entrypoint, and making the entrypoint to behave like the image were launched in interactive mode (i.e. running bash) if START_ODOO is false.

Regards,