Assets directory not writable

[VajraCool]

I am facing the issue as mentioned below. I have tried removing the container and even removed image as well and tried to run

here is my docker-compose file

# cat docker-compose.yml
---
version: "2"
services:
   homer:
     image: b4bz/homer
     container_name: homer
     volumes:
       - ./assets/:/www/assets
     ports:
       - 89:8080
#below lines are commented based on github
#https://github.com/bastienwirtz/homer/issues/325#issuecomment-1114019406
#https://github.com/bastienwirtz/homer/issues/441#issuecomment-1114170968
    #  environment:
    #    - UID=1000
    #    - GID=1000
     user: 1001:1001
     restart: unless-stopped

error I see

No configuration found, installing default config & assets

Assets directory not writable. Check assets directory permissions & docker user or skip default assets install by setting the INIT_ASSETS env var to 0

I see the permissions are there to write

# ls -ltr
total 8
drwxr-xr-x 2 root root 4096 May 31 04:07 assets
-rw-r--r-- 1 root root  244 May 31 04:10 docker-compose.yml
# whoami
root

I am not sure what exactly this gonna do skip default assets install by setting the INIT_ASSETS env var to 0 ?

is there something I am missing ?

Note - created new issue as this issue is closed.

[bastienwirtz]

Hey 👋
As I was saying on the other issue, your assets directory is owned by root the user / group of the assets dir should match the user: xxxx:xxxx directive in your compose file. This error is normal and expected in this case.

set INIT_ASSETS to 0 will prevent homer to try to write into the directory, but you will have to configure homer entirely from scratch. The defaults assets provides a base config you can easily edit to your needs.

[WarmEthernet]

I'm having this same issue now after updating my server. My config looks similar as above and the GID and UID in the docker-compose match the owner of the assets directory. I have other containers running as expected on the same server and Homer seems to be the only one that broke during the update.

Edit: Nevermind, I went to the other thread and used solutions posted there. Its working again.

[VajraCool]

but you will have to configure homer entirely from scratch.

@bastienwirtz you mean , I should delete images , container , directory and do everything by setting env variable ?

Thank you for the response.

[tropics1999]

I had the same problem using 'user: 1000:1000', I tried several different directories but none worked. I changed it to 'user: 0:0' and this worked for me. I am far from a Linux expert though, so this may not be recommended.

[e1ke]

I had the same problem using 'user: 1000:1000', I tried several different directories but none worked. I changed it to 'user: 0:0' and this worked for me. I am far from a Linux expert though, so this may not be recommended.

that helped me a lot, thanks mate

[bastienwirtz]

@tropics1999 @e1ke user 0:0 will make the container run as root user. It's not recommended for security reason. You should try to fix the permission issue.

@bastienwirtz you mean , I should delete images , container , directory and do everything by setting env variable ?

I mean if you skip asset install you will have to create a config.yml file in the assets dir by hand, because homer will not bootstrap the config for you.

@WarmEthernet That's weird, could you run those commands and share the result ?

# You might need to replace "homer" by your container name if different
docker inspect homer | grep User
docker inspect homer | grep assets

# Show ownership and permissions on your mounted assets dir
ls -la <path/to/asset/dir>

That would help me understand. Thanks you 🙏

[bastienwirtz]

@VajraCool @tropics1999 @e1ke you can also run the commands I suggested to WarmEthernet and share the result. It would help debug.

[e1ke]

@VajraCool @tropics1999 @e1ke you can also run the commands I suggested to WarmEthernet and share the result. It would help debug.

does this help?

[bastienwirtz]

@e1ke Could you also share the docker-compose configuration or the command you use to run docker ? Thanks!

[e1ke]

@e1ke Could you also share the docker-compose configuration or the command you use to run docker ? Thanks!

version: "2"
services:
  homer:
    image: b4bz/homer
    container_name: homer
    volumes:
      - /var/lib/docker/volumes/homer/:/www/assets
    ports:
      - 8095:8080
    #environment:
    #  - UID=1000
    #  - GID=1000
    restart: unless-stopped
    user: 0:0

[mbaiti]

had the same problem after updating to the latest image.
Ownership of my assets folder was 911, don't know why.

After changing it to (in my case) the pi user
sudo chown pi:pi homer
it works perfectly again.

[dockerenthusiast]

I have the same problem with the latest image in my raspberry pi but I am new to all this. could you please elaborate on what you did please?

[petechua]

I reverted back to b4bz/homer:22.02.2-arm64v8 and the original configs is working fine now. I believe "something" is broken in the latest image.

[anjanms]

It appears there are two issues at play here. I've just stumbled into this after updating to the latest image.

1. The entrypoint is trying to create the default configuration at every startup.

The entrypoint is looking for the legacy /www/config.yml rather than /www/assets/config.yml. When it doesn't find /www/config.yml it tries to create the default config. Which then leads to;

2. The UID:GID change causing the assets directory to be non-writable.

Under normal circumstances assets being non-writable shouldn't be an issue. But in this case the container dies as it thinks there is no config and it can't create the defaults.

Disabling the default configuration creation via INIT_ASSETS=0 allows the container to start normally. Despite the non-writable directory.

[poldim]

Disabling the default configuration creation via INIT_ASSETS=0 allows the container to start normally. Despite the non-writable directory.

This solved it for me.

@bastienwirtz I probably haven’t done a docker-compose pull in about 2-4 weeks, but nothing on my server has changed that would initiate this error. Initially when I setup homer earlier this year, it had no issues creating the initial config. Is there something that’s been changed in project that would cause this issue?