Closed Sn3ider closed 3 months ago
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.
@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.
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.
@jorenn92 Thanks for jumping in.
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.
This is a typical example that I am missing a minor thing which is causing me a major headache :D
Can't help you any further. I never used container manager. I do everything with docker -compose on my synology.
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.
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.
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.
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
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.
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 :)
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.
Feature request: https://github.com/jorenn92/Maintainerr/discussions/1084
@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.
@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.
Describe the bug Synology DS920 DSM 7.2.1-69057 Update 5, Container Manager. Maintainerr does not have access to the data folder to save its configuration. User account is set by adding PUID and PGID. IDs are correct and checked through SSH. With my admin IDs the issues remains the same. Starting with Privileged user won't have any effect. Privilege inspector on the folder shows R/W rights for both the User and the Group. Adding them as Owners won't make any difference.
I redacted the PUID and PGID in the following configuration.
Configuration { "CapAdd" : [], "CapDrop" : [], "cmd" : "", "cpu_priority" : 50, "enable_publish_all_ports" : false, "enable_restart_policy" : true, "enable_service_portal" : null, "enabled" : false, "env_variables" : [ { "key" : "PATH", "value" : "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" }, { "key" : "NODE_VERSION", "value" : "20.11.1" }, { "key" : "YARN_VERSION", "value" : "1.22.19" }, { "key" : "NODE_ENV", "value" : "production" }, { "key" : "DEBUG", "value" : "false" }, { "key" : "GIT_SHA", "value" : "995d01eb2a212f0167b96c274a26137c3f395b3a" }, { "key" : "VERSION_TAG", "value" : "stable" }, { "key" : "YARN_INSTALL_STATE_PATH", "value" : "/tmp/.yarn/install-state.gz" }, { "key" : "YARN_GLOBAL_FOLDER", "value" : "/tmp/.yarn/global" }, { "key" : "YARN_CACHE_FOLDER", "value" : "/tmp/.yarn/cache" }, { "key" : "UV_USE_IO_URING", "value" : "0" }, { "key" : "HOME", "value" : "/" }, { "key" : "PUID", "value" : ""
},
{
"key" : "PGID",
"value" : ""
},
{
"key" : "TZ",
"value" : "Europe/London"
}
],
"exporting" : false,
"id" : "075a7425dc4ba798aa38f8dd8c1dfaf98952bb47b088dd1afcfe3b0d5a226133",
"image" : "jorenn92/maintainerr:latest",
"is_ddsm" : false,
"is_package" : false,
"labels" : {
"org.opencontainers.image.created" : "2024-03-25T14:41:52.660Z",
"org.opencontainers.image.description" : "Looks and smells like Overseerr, does the opposite. Maintenance tool for the Plex ecosystem",
"org.opencontainers.image.licenses" : "MIT",
"org.opencontainers.image.revision" : "995d01eb2a212f0167b96c274a26137c3f395b3a",
"org.opencontainers.image.source" : "https://github.com/jorenn92/Maintainerr",
"org.opencontainers.image.title" : "Maintainerr",
"org.opencontainers.image.url" : "https://github.com/jorenn92/Maintainerr",
"org.opencontainers.image.version" : "main"
},
"links" : [],
"memory_limit" : 0,
"name" : "Maintainerr",
"network" : [
{
"driver" : "bridge",
"name" : "arrbridge"
}
],
"network_mode" : "arrbridge",
"port_bindings" : [
{
"container_port" : 6246,
"host_port" : 6246,
"type" : "tcp"
}
],
"privileged" : false,
"service_portals" : [],
"shortcut" : {
"enable_shortcut" : false,
"enable_status_page" : false,
"enable_web_page" : false,
"web_page_url" : ""
},
"use_host_network" : false,
"version" : 2,
"volume_bindings" : [
{
"host_volume_file" : "/docker/maintainerr/opt/data",
"is_directory" : true,
"mount_point" : "/opt/data",
"type" : "rw"
}
]
}