Do you have documentation on how to implement this with NextJS ? I'm not really familiary with the PUID and PGID variables and don't know how to leverage them once they are set. Links/PRs welcome!

Not really. I don't even think it should be done by NextJS. Those are variables tied with docker environment.

So how would I go about implementing the support of these env variables ?

This might help https://raphaelpralat.medium.com/system-environment-variables-in-next-js-with-docker-1f0754e04cde

This might help https://raphaelpralat.medium.com/system-environment-variables-in-next-js-with-docker-1f0754e04cde

I know how to use environment variables with NextJS, that's how I implemented the password. Problem is that I don't know what the env variables OP suggests are supposed to be doing

Problem is that I don't know what the env variables OP suggests are supposed to be doing

Their meaning is that they specifies with user would run the docker container so it's not needed to be run as root

Example: As PUID i will specify 1000 which is my user account and the same thing for PGID as user group. This way i can define i want to run this docker container as user that i specified in PUID and PGID (it's ID specifically). You can see what i'm writting about here, in Parameters section

I don't think PUID and GUID has anything to with NextJS, as @Pheggas said it's just defining which user and group the docker container uses. I have no idea how to pass this to the actual container, but I'll do some research.

Linuxserver seems to be using S6 to manage permissions. https://discourse.linuxserver.io/t/how-to-add-puid-pgid-function-into-docker-image/2474

@walkxcode I don't see a problem using FROM ghcr.io/linuxserver/baseimage-alpine:3.12 as base image.

Just need to document the benefits this change could offer

Should be added with #317

hello, this does not seem to address the issue if I understand correctly ... root user is still used in container and config files are created with root.
my docker compose file :

---
version: '3'
services:
  homarr:
    container_name: homarr
    image: ghcr.io/ajnart/homarr:latest
    environment:
      - PUID=998
      - PGID=100
      - TZ=Europe/Paris
    volumes:
      - /home/admin/configs/homarr/configs:/app/data/configs
      - /home/admin/configs/homarr/icons:/app/public/icons
    restart: unless-stopped
    ports:
      - '7575:7575'

content of conf folder :

/home/admin/configs/homarr $ ll
total 16
drwxr-xr-x  4 root  root  4096 Aug 21 14:57 .
drwxr-xr-x 25 admin users 4096 Aug 21 14:57 ..
drwxr-xr-x  2 root  root  4096 Aug 21 15:01 configs
drwxr-xr-x  2 root  root  4096 Aug 21 14:57 icons

Dear @ajnart
Can we re-open this? The image still runs as root, since #326 changed the base image back from ghcr.io/linuxserver/baseimage-alpine:3.16 (which implemented PUID and PGID and the ability to NOT run as root) to node:16-alpine

One should definitely NOT run an image as root...

Thanks!

Hi @croneter 👋,
thank you for bringing this up again.
I'll re-open the issue for now and we'll see what we can do.
Feel feee to submit a pull request if you want

JFYI @ajnart

Hello @ajnart this should be reopened because it's still an issue in version 0.11 :(

Why has this not been fixed? @ajnart , you told me that it was fixed. I'm reopening this...

Why has this not been fixed? @ajnart , you told me that it was fixed. I'm reopening this...

problem was that environnement variables were not exported in the image. Like docker run -e PASSWORD something didn't work, I think the environment variables weren't passed to the user . Is anyone finds a fix please make a PR because I didn't find one

Hey @ajnart, I may spend some time this week looking at this issue. May I ask why did you revert the base image change from ghcr.io/linuxserver/baseimage-alpine:3.16 to 'node:16-alpine'?

Did something break with the linuxserver image?

After a lot of searching, the current answer seems to be the user field.
add -u "PUID:GUID" to the command or user: "PUID:GUID" in compose.
All the folders mounted need the correct permissions otherwise nothing will work.
Also, put the command or the line "first", as everything that is after will be executed as said user, but if not, will be executed as root.

From my testing, this works with no problems, but I'd love if anyone that cares could try it out and maybe point out if something is missing.

@nyok1912 Tagging you as you made the recent issue about it.

After a lot of searching, the current answer seems to be the user field. add -u "PUID:GUID" to the command or user: "PUID:GUID" in compose. All the folders mounted need the correct permissions otherwise nothing will work. Also, put the command or the line "first", as everything that is after will be executed as said user, but if not, will be executed as root.

From my testing, this works with no problems, but I'd love if anyone that cares could try it out and maybe point out if something is missing.

@nyok1912 Tagging you as you made the recent issue about it.

That sounds very well, but i'm not understand, that is working for you? i'm trying with minimal compose and fresh folder without any data without success...

You need to manually create the folders with the right permissions.
I suggest using install -o 1000 -g 1000 /path/to/folder

You have reason! That works! Then i think, only necessary run script to fix permissions inside contaner?

As far as I can tell, everything should be running as the user you set.
Is there an actual need to change anything further?
Could you show us what is still running as root that you wouldn't want to and why?

Not all works correct, docker integration is now not working:

homarr  |  ERROR  The docker integration failed with the following error: TRPCError: Unable to get containers
homarr  | 
homarr  | 
homarr  |  ERROR  The docker integration failed with the following error: TRPCError: Unable to get containers

Reason for keep synced user permission under each home folder is many when binded mount volumes based.

• Consistence: under home user, user can view, edit and remove files without sudo.
• Security
• Functionality: user can have other services or containers same as file editor or backup same as duplicati, when using correctly permissions in each container, cannot interactuate with homarr data because user is not owner of this files.

There will probably be more reasons I can remember in the future or other users tell more reasons for this, each time docker containers is more supporting this little feature.

Yes that's because the permissions to the docker integration file might need to be root, which your container isn't in this case.
I understand why you want to have different permissions, what I was asking was why wouldn't using "user" be enough, since that's what you're supposed to use with docker.
Under this solution, all files created by homarr use the set user as base.
For the reasons you enunciated, all seem to be covered by the built in user from docker.

As for the docker.sock, see if you can change the file's permissions somehow.

I looked a bit, seems you only need to add the user to the docker group:
sudo usermod -aG docker 1000
And then restart your docker daemon
But this basically gives root access from what I read.

I understand that you can't want to restrict access and at the same time give it full control over your docker.

Uhm... change docker.sock permissions in host for addapt to each user is not good option... containerized app must be addapted for works with host resources keeping host rules, id's, etc... using customizable enviroment var to fine set working with host.

I think Cointainer can have a supervisord to start processes and adjust internal user id and privileges, I have done this before with good result

If you have any idea on how to implement this into homarr, you're welcome to contribute.
Since we've been changing the run script, dockerfile and base image a lot lately, there's a chance that any modification won't stick, like this thread has shown to be happening on previous attempts at implementing it.
This solution I am giving is the simplest and closest we can offer that will stay consistent in the future.

Ok, let's me try!

If you have any idea on how to implement this into homarr, you're welcome to contribute. Since we've been changing the run script, dockerfile and base image a lot lately, there's a chance that any modification won't stick, like this thread has shown to be happening on previous attempts at implementing it. This solution I am giving is the simplest and closest we can offer that will stay consistent in the future.

you have telegram?
It would be nice to be able to ask some questions with low relevance for this thread, my telegram user is @nyok1912

I would rather use discord if you're ok with it, this is where we converse within the community.
https://discord.com/invite/aCsmEV5RgA