Synology Permission Query - Could not create or access (files in) the data directory. Please make sure the necessary permissions are set about maintainerr HOT 13 CLOSED

Can't help you any further. I never used container manager. I do everything with docker -compose on my synology.

from maintainerr.

Is your volume mount to set correct.
Needs to be something like /volume1/docker/appdata/maintainerr:/opt/data
And make sure /volume1/docker/appdata/maintainerr or whatever you use exists before starting the container.

from maintainerr.

@BaukeZwart Thanks for the quick reply.
The mount volume is selected from the Synology Container manager GUI, and volume1 never added there.
The volume mounting shows correctly within the UI, so that shouldn't be a problem.

Strange that volume1 is not showing when I export the config.

from maintainerr.

The volume should exist on your host before starting the container. Also, make sure the root volume directory (in your case: /volumel/docker/maintainerr/opt/data) is owned by the correct owner & group.

from maintainerr.

@jorenn92 Thanks for jumping in.
#1 Volume exists, I used Maintainerr before v2.0
#2 Root Volume Directory (/volumel/docker/maintainerr/opt/data) has the docker user set up as owner.
In the editor it only allows me to assign either the Group or the user.
Tried with the user and the group set as the owner, no luck.

#3 Setup

#4 With the root account I ssh'd into the NAS, used CHOWN to have the user and group as owner yet exactly the same issue.

This is a typical example that I am missing a minor thing which is causing me a major headache :D

from maintainerr.

You could try to temporarily test 777 permissions. If it still won’t come up, there’s something else at play. If it does, you’d need to figure out why maintainerr’s user is not able to write in the folder.

from maintainerr.

Can't help you any further. I never used container manager. I do everything with docker -compose on my synology.

@BaukeZwart I thought you can only manage Docker with Portainer or Container Manager with Synology.
Are you referring to the User Defined Script way, or there is another version that I am not aware of? :D

EDIT: Too much thinking. It is simply using the Container Manager with Project, rather than installing the image directly with variables.

from maintainerr.

You could try to temporarily test 777 permissions. If it still won’t come up, there’s something else at play. If it does, you’d need to figure out why maintainerr’s user is not able to write in the folder.

@jorenn92 Tested. With 777 it works like a charm. Here comes the hard part, figuring out why on earth my user does not have access while it is set to be the owner of this folder.

from maintainerr.

Starting the container from Container Manager Image

Issue identified. UID:GID (PUID:PGID) is 1000:1000 even if I set UID and GID as environmental variables.
I even added user as variable which still had the same issue.
This then caused the access issue where the default user obviously should not have access to the given folder.

I checked it by using container terminal with /bin/sh command and id
How to: https://www.youtube.com/watch?v=995uUSleHsg

Using Project and compose file

I used chmod and chown to change the opt directory with recursive to 0755 which did the trick.
As a result, the user defined in the compose file could read/write the mounted folder, and it even picked up the original configuration.

Conclusion

Variables are not amending the GID and UIDs and the container starts with the default 1000:1000.
Currently the only workable solution is using the compose file which had been mentioned by @BaukeZwart.

@jorenn92 would it be possible to define UID and GID as environmental variables in future releases? It would help with the default Synology container manager to simply add them during the installation and would not require to tweak the compose file.

Thanks :)

from maintainerr.

I am marking it as complete as the original issue is investigated and resolved.
A feature request would be good to add PGID and PUID for the environmental variables.

from maintainerr.

Feature request: #1084

from maintainerr.

@Sn3ider, sorry to bring this issue up again, but weren't you able to use Docker's built-in 'user' directive? We opted to support this mechanism instead of PUID and PGID at some point, as you still have to start the container as root using that approach.

With the user directive, the image is fully rootless from the start. The user you specify in this directive has access to the files and folders of the 'node' user, which is why the file ownership doesn't change.

from maintainerr.

@Sn3ider, sorry to bring this issue up again, but weren't you able to use Docker's built-in 'user' directive? We opted to support this mechanism instead of PUID and PGID at some point, as you still have to start the container as root using that approach.

With the user directive, the image is fully rootless from the start. The user you specify in this directive has access to the files and folders of the 'node' user, which is why the file ownership doesn't change.

@jorenn92 technically there is no default user in Synology Container Manager, or I did not find the default IDs on the Synology support side.

The UID and GID needs to be defined for every container upfront if I want the container to save on shared locations.
However, if I am not defining any IDs then the 1000:1000 user will be used. That is not a default user in my Synology NAS, but I could ssh and add the necessary permissions to the folders, but I don't want to provide accesses where I have no proper control over it.

from maintainerr.