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.

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.

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.

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.

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

@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 🙏

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

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

does this help?

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

@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

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.

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?

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.

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.

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?

I found this issue because loading Homer in the browser shows an alert box with this text:

⚠️ Error loading configuration
Error: Forbidden: [object ReadableStream]

I double checked that the assets directory's owner and group matched the UID and GID environment variables I'm using in my docker-compose.yml file.

It seems Homer is not respecting these environment variables. docker inspect $CONTAINER_ID | grep User shows "1000:1000" which are the default values in the Dockerfile and not what I set via environment variables.

I had to add user: $UID:$GID to my docker-compose.yml file. Then the docker inspect output showed the correct UID and GID and I no longer got the above error when loading Homer in the browser.

Also have this issue when upgrading to the latest image.
Since I have to run my pods as root, I don’t really have a choice when it comes to mapping the users to something else than root. So what I did is to set the user to root :

podman run --user 0:0 -e INIT_ASSETS=0 ...

But I still get :

Error loading configuration
Error: : [object ReadableStream

Even when setting proper file permissions :

[root@**]# podman inspect homer | grep User
"User": "0:0",
"UsernsMode": "",

[root@**]# podman inspect homer | grep assets
"Destination": "/www/assets/",
"--volume=/srv/homer/:/www/assets/:z",
"/srv/homer:/www/assets/:rw,rprivate,rbind"

It’s very weird.
I think its due to : #421

After investigating more I can see that root is correctly mapped in the container but lighttpd is still under lighttpd :

/www # ps aux
PID USER TIME COMMAND
1 root 0:00 /bin/sh /entrypoint.sh
6 lighttpd 0:00 lighttpd -D -f /lighttpd.conf
7 root 0:00 /bin/sh
14 root 0:00 ps aux

It will obviously not even be able to access files the entrypoint settled as root when starting.

So I try to force all users to root by setting the namespace to the host root :

--userns=host

Unfortunately it still can’t access files on the host. it is not a SELinux issue as I tried while disabling it.

@jimmycuadra This is the normal behavior. env vars are used during the image build only (that why these variable are not listed in the documentation), the user option is the way to override it.

@mguaylam Indeed it's related to #421. Please do not use 0:0. It's unsecure and the whole point of #421 is to avoid tha. Just put the same UID/GID on both the user docker option and your asset folder and you will be fine.

Hey @ALL !

I will write a detailed section about permissions management in the documentation, but the tl;dr is:

• Do not use env var to set the GID / UID of the user running container. Use Docker user option.
• Do not use 0:0 as a user value, it would be a security risk, and it's not guaranty to work.
• Just make sure your mounted assests directory have the same GID / UID you put in the user option, and that the read and write permission is granted for the user or the group.

And you should be fine.

Ok it indeed does not work with root anymore. Changing it to another user did work. Thank you.

The behavior has changed recently and never been properly documented. I just added some documentation about that in the README and the troubleshooting page.

Hope it helps. I think we covered the cause, debugging and resolution of the issue in this thread, so I'm closing the issue. Thank you all!

@bastienwirtz
Just a point of reference, that the linux server uses the method of setting the user via environmental variables on their large fleet of containers. At no fault of yours, a lot of people may assume that it's possible as it's likely they're using those containers already

In my case the solution was to create the /home/assets directory via SSH first (rather than via docker-compose) as it seems it was being created with root credentials rather than user ones

Hello!

I still cannot get it to run. I am using mac os x and a docker yaml.
I created the folders manually and set the values for the assets folder like you described in the readme.
if i analyze it i get the following return:

drwxr-xr-x 2 1000 1000 64 22 Jul 14:12 assets\

is this ok?
my compose file:

thanks for you help!

error:
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

EDIT: Running it with 0:0 user works - i read it's not recommendet but i cannot find another way running mac os x

i had the same issue which (in my case) was caused by an outdated version of libseccomp (2.3.3.4)

with an update to the latest version (2.5.4.1) i was able to fix the issue without manually changing permissions on the directories

wget http://ftp.uk.debian.org/debian/pool/main/libs/libseccomp/libseccomp2_2.5.4-1%2Bb1_armhf.deb
dpkg -i libseccomp2_2.5.4-1+b1_armhf.deb

docker run -d -p 8095:8080 -v /home/pi/homer/Config/Homer/assets:/www/assets --name="homer" -u:1000:1000 --restart=always b4bz/homer:latest

If you write it like this, it works fine.

you just need to add -u:1000:1000

I found this issue because loading Homer in the browser shows an alert box with this text:

⚠️ Error loading configuration
Error: Forbidden: [object ReadableStream]

I double checked that the assets directory's owner and group matched the UID and GID environment variables I'm using in my docker-compose.yml file.

It seems Homer is not respecting these environment variables. docker inspect $CONTAINER_ID | grep User shows "1000:1000" which are the default values in the Dockerfile and not what I set via environment variables.

I had to add user: $UID:$GID to my docker-compose.yml file. Then the docker inspect output showed the correct UID and GID and I no longer got the above error when loading Homer in the browser.

Thank you for doing this as the readme doesn't mention anything about it. I had the same problem. I initially suspected something was up as the permissions issues vanished only after I used a uid and gid of 1000 in my docker run command.

Hey @ALL !

I will write a detailed section about permissions management in the documentation, but the tl;dr is:

• Do not use env var to set the GID / UID of the user running container. Use Docker user option.
• Do not use 0:0 as a user value, it would be a security risk, and it's not guaranty to work.
• Just make sure your mounted assests directory have the same GID / UID you put in the user option, and that the read and write permission is granted for the user or the group.

And you should be fine.

Out of curiosity, I run this docker container inside an lxc container. If I run this as root - since this container really only has access to another container - would this be ok?

Can you fix is , there is still and issue.
The issue is your image is not our PC configurations.

version: "2"
services:
  homer:
    image: b4bz/homer
    #To build from source, comment previous line and uncomment below
    #build: .
    container_name: homer
    volumes:
      - ./homer/assets/:/www/assets
    ports:
      - 8081:8081
    user: 1000:1000 # default
    environment:
      - INIT_ASSETS=1 # defaul
      - PORT=8081
      - SUBFOLDER=/homer

total 16
drwxr-xr-x 3 pi   pi   4096 Jan  8 11:25 .
drwxr-xr-x 6 pi   pi   4096 Jan  8 11:18 ..
-rw-r--r-- 1 pi   pi    362 Jan  8 11:34 docker-compose.yml
drwxr-xr-x 3 root root 4096 Jan  8 11:25 homer

uid=1000(pi) gid=1000(pi) groups=1000(pi),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),104(input),106(render),108(netdev),995(docker),997(gpio),998(i2c),999(spi)

Other docker compose create volumes with 1000 user but yours create as root, you have something wrong in your image.

@asyba You nailed it... we shouldn't have to fix the permissions when running this image.... never have, and I'm not starting today. I was hoping to give homer a spin, but simply won't today based on principle. Do I know how to change permissions on the assets folder? Sure... have I ever had to do that for a container that creates its own folders before? No. I'll check back again some day down the road.

100% Homer image issue, not my permissions. I run the same CLI template for all other images with no problems, but Homer likes the Root.

docker run -d \
    --name Homer \
    -p 8484:8080 \
    -e PUID=1000 \
    -e PGID=1000 \
    -e UMASK=002 \
   -e TZ=America/Dallas \
    -v ~/docker-data/homer:/www/assets \
    --restart=always \
    b4bz/homer:latest

Results in

kff@udocker:~/docker-data$ ls -al
total 44
drwxrwxr-x 11 kff  kff  4096 Feb  6 13:36 .
drwxr-xr-x  7 kff  kff  4096 Feb  6 13:21 ..
drwxr-xr-x  2 root root 4096 Feb  6 13:21 homer
drwxrwxr-x  6 kff  kff 4096 Feb  6 12:11 lidarr
drwxr-xr-x  2 kff  kff  4096 Jan 25 02:49 nzbget
drwxrwxr-x  5 kff  kff  4096 Jan 30 11:46 overseerr
drwxrwxr-x  6 kff  kff  4096 Feb  6 13:31 prowlarr
drwxrwxr-x  5 kff  kff  4096 Jan 24 02:11 qbittorrent
drwxrwxr-x  6 kff  kff  4096 Feb  6 13:01 radarr
drwxrwxr-x  6 kff  kff  4096 Feb  6 13:31 sonarr
drwxr-xr-x  3 kff  kff  4096 Jan 29 16:49 uptime-kuma
kff@udocker:~/docker-data$ 

chown kff:kff homer
run the above CLI, and everything works as expected.

Not sure if is relevant or not, but I was having the same issue. My host is a Synology NAS.

I downloaded the image from hub.docker.com, but I couldn't mount the volume. I run it without the volume mount to be able to run it, on the running container on /etc/passwd for user lighttpd:x:1000:65533.

I then set the permission on the folder to be mounted on the host to 1000:65533, rerun the container with the volume mount, and it ran successfully. Files created in the folder use 1000:1000.

Cheers

@Gugatec this worked for me as well.

Running on my Synology NAS with Container Manager.

The NAS folder that is being mapped to the container needs updated permissions. Create the folder and then either SSH or run a Scheduled Task to update the owner of the folder you've created in your NAS. We're using the lighttpd 1000:65533 user:group combo that the container uses (to confirm, you can run the container with INIT_ASSETS: 0 and create a new shell on the container by clicking the "Create" dropdown and clicking "Launch with command" and entering sh (the container doesn't have bash).

sudo chown 1000:65533 /path/to/folder/homer

for example, for me:

sudo chown 1000:65533 /volume1/docker/containers/homer

Then add that path as a linked folder on the container's Volume Settings, linking it to the assets folder:

/volume1/docker/containers/homer/ -> /www/assets/

and I set my UID and GID to the same as above, so:

UID: 1000
GID: 65533
INIT_ASSETS: 1

This is still broken but I can confirm that the tricks in this thread work - change your /homer/assets folder's owner to your user and not root, and do not use any .env fields in your docker-compose. Instead write out everything. This makes it more inconvenient to change these settings but it does work.

This is still broken but I can confirm that the tricks in this thread work - change your /homer/assets folder's owner to your user and not root, and do not use any .env fields in your docker-compose. Instead write out everything. This makes it more inconvenient to change these settings but it does work.

@nmhare On my synology, it only worked with pid/gid 1000:65533 (these are the ids used inside the container) and not my synology user pid:gid.

I am facing the same issues on my Synology. I have the docker-compose as follows:

version: "2"
services:
  homer:
    image: b4bz/homer
    container_name: homer
    volumes:
      - /volume1/docker/homer/assets:/www/assets
    ports:
      - 8095:8080
    environment:
      - PUID=1026
      - PGID=100
      - INIT_ASSETS=1
    restart: unless-stopped

I have to chmod 777 to homer/assets folder. That solve the assets not writable error.

Thanks for all the post here. I solve the write issue with the following command.

sudo chown 1000:1000

*for future reference

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.

This helped me, thank you so much. for some reason it was owned by root, changing ownership of the folder and subfolder worked for me.