Cannot get homarr v1.0.0-beta4 to start (permissions)
I have been unable to get appropriate permissions set up for /appdata. Tried setting perms to 777, subdirectories are created but container is unable to chown. Recently tried just using a volume instead of a bind and now getting
mkdir: can't create directory '/appdata/db': Permission denied Is there a way to set the uid/gid that the container runs as? Passing them as env vars did not appear to workSolution:Jump to solution
Okay I just setup portainer and took a look. It seems like you currently have somehow defined that it needs to run with the
nextjs user see your inspection in Config > User above Volumes. For me this field is an empty string: "User": ""
So I guess you have configured this somewhere in your portainer configuration...42 Replies
Thank you for submitting a support request.
Depending on the volume of requests, our team should get in contact with you shortly.
⚠️ Please include the following details in your post or we may reject your request without further comment: - Log (See https://homarr.dev/docs/community/faq#how-do-i-open-the-console--log) - Operating system (Unraid, TrueNAS, Ubuntu, ...) - Exact Homarr version (eg. 0.15.0, not latest) - Configuration (eg. docker-compose, screenshot or similar. Use ``your-text`` to format) - Other relevant information (eg. your devices, your browser, ...)
❓ Frequently Asked Questions | Homarr documentation
Can I install Homarr on a Raspberry Pi?
Can you send your compose file?
I had this issue too. After folder created i checked the permissions and it was read / write I add execute and it’s fix the problem
Didn't use compose, just built it in portainer but here's the config inspection there with RW on the volume mounted to /appdata
I've tried adding 777 to the db and redis folders it creates, but it still desperately wants to chown the folders and won't start unless its able to
Did you use -r?
sudo chmod -R 777 /homarr
You need to run this command only on homarr folder
-r stands for recursive so it applies to everything inside and not just the folder.
you can do
ls -lhs to check the permissions, owner and groups of a file or directory.its able to create the directories, and these are what I see from the host, but its failing all the chown operations in the container and restarting
I don't know what the 1001 and 65533 user / groups are, I haven't set those and I'm unable to tell the container to use different uid/gid
1000 and 1001 are usually the first user made for the system.
65533 is the last group ID (there can't be a higher ID than this one).
It's not really important though if you end up doing a chmod -R 777 anyway
Here we can see your folders have 755 permissions, not 777. And I wouldn't be able to tell you for the nested files
With the parent folder set to 777, these are the permissions the container creates the folders with. There are no items in the folders, and recursively marking everything in the parent folder 777 results in the same error with the chown operation not being permitted. Identical behavior when using a docker volume vs a bind
Also, the owner being 1001 seems to mean you should already have the right owner.
Try to keep everything and just manually chown the folders and the contents.
sudo chown -R 1001:1001 /mnt/config/homarr-beta
Then do the same with sudo chmod -R 777 /mnt/config/homarr-betaokay, got a different error now
su-exec: setgroups(1001): Operation not permitted
could you share the ls -lhsR instead? it would show us the persmissions and files that are in the directories too
I'm out of ideas, permissions are a pain sometimes. @Meierschlumpf ?
Do you have a user with id
1001 on your instance? If so maybe it's conflicting with the one in the container (probably not)
Can we maybe start over, because with the current state I don't think we will get anywhere
What user runs portainer, does it have access to create the directories and chown them?
Also you don't specify a user in your portainer that should be used to run it I guess, right? If so thats good, if you specify one please try again with removing himps -aux shows this for the portainer process: root 3072 0.3 0.4 1304280 75432 ? Ssl 09:23 0:02 /portainer
so I assume root is running it, and should have access to create directories / chown. I've also tried setting the /appdata bind to a directory in my user's home directory, with the exact same errorsWhat exactly is the error you get from chown?
Okay I would suggest that we in a first step find out why this is the case. I'll publish a specific image tag for you that will run the
whoami command before the chown. Then we will know, why we are not allowed to change it. You don't have specified a User under Runtime & Resource in the Advanced container settings, right?No user set. Thank you for the help!
Okay good that there is no user
Then it should use the container default in theory
When I haven't screwed up with triggering the release pipeline, I'll let you know in about 25 minutes when the image tag
portainer-operation-denied is ready
I've added the following two lines btw:
In my research I did see that whoami could be useful in this context but didn't want to mess with the start command
Okay image tag is ready
same command from host system
Have you changed something with
chown yourself or why now the su-exec failed and no longer the chown?
Also it's pretty weird that it already has user nextjs before the su-exec. Because it should be rootMy apologies, that was after I chowned it on the host system. This is from a freshly created and chmod 777'd bind:
with this being from host system
And one without any chmod?
that one fails with
mkdir: can't create directory '/appdata/db': Permission denied and no echoOkay I see, so I guess I should have placed the whoami before the mkdirs
New image with newly positioned debug statements is up, you can try again
Okay it's weird that it still runs with
nextjs userI had homarr-alpha running without issues on a NAS smb share with the nobody:share user/group, but that NAS is down today due to a bad power supply so I was trying to set up the mount directly on the host. Regular <1.0 homarr works without issues too
Yes as we previously had run the things as root (in regular < 1.0)
You use portainer you said, right?
I'll try to setup it on my machine and let you know if I can reproduce the issue
yep, I'm on portainer 2.21.4
Solution
Okay I just setup portainer and took a look. It seems like you currently have somehow defined that it needs to run with the
nextjs user see your inspection in Config > User above Volumes. For me this field is an empty string: "User": ""
So I guess you have configured this somewhere in your portainer configurationHmm alright I'll take a look and see if I can remove that. Thanks!
I tried just creating a new container in portainer with a new directory and it looks like that worked. In hindsight, I may have been duplicating my homarr-alpha container and maybe that's how the user got in somehow
Okay great that you were able to solve it!