{"id":19388276,"url":"https://github.com/mk-fg/reliable-discord-client-irc-daemon","last_synced_at":"2025-04-07T10:29:08.430Z","repository":{"id":41174339,"uuid":"162937014","full_name":"mk-fg/reliable-discord-client-irc-daemon","owner":"mk-fg","description":"Reliable personal discord-client to irc-server translation daemon","archived":false,"fork":false,"pushed_at":"2025-04-05T21:56:42.000Z","size":2132,"stargazers_count":77,"open_issues_count":1,"forks_count":10,"subscribers_count":8,"default_branch":"master","last_synced_at":"2025-04-05T22:26:06.214Z","etag":null,"topics":["asyncio","bouncer","chat","discord","irc","proxy","python"],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"wtfpl","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/mk-fg.png","metadata":{"files":{"readme":"README.docker-permissions.md","changelog":null,"contributing":null,"funding":null,"license":"COPYING","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-12-24T01:33:20.000Z","updated_at":"2025-04-05T21:56:45.000Z","dependencies_parsed_at":"2023-02-19T13:01:07.189Z","dependency_job_id":"b00bb104-03d0-462d-beb1-bd36fe72508a","html_url":"https://github.com/mk-fg/reliable-discord-client-irc-daemon","commit_stats":{"total_commits":659,"total_committers":5,"mean_commits":131.8,"dds":0.01669195751138086,"last_synced_commit":"09b563ca20e562aabf3ed9635f0d65b9dd06eae4"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mk-fg%2Freliable-discord-client-irc-daemon","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mk-fg%2Freliable-discord-client-irc-daemon/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mk-fg%2Freliable-discord-client-irc-daemon/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mk-fg%2Freliable-discord-client-irc-daemon/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/mk-fg","download_url":"https://codeload.github.com/mk-fg/reliable-discord-client-irc-daemon/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247635174,"owners_count":20970687,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["asyncio","bouncer","chat","discord","irc","proxy","python"],"created_at":"2024-11-10T10:12:19.910Z","updated_at":"2025-04-07T10:29:08.401Z","avatar_url":"https://github.com/mk-fg.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Permission issues with docker\n\nCommon issue with unprivileged containers running in docker might look like this:\n\n```\nFailed to create initial configuration file [ config.ini ]:\n  [PermissionError] [Errno 13] Permission denied: 'config.ini'\n```\n\nUnfortunately it's somewhat complicated, and I don't know a good-and-easy fix for this.\\\nThis small document tries to explain what the issue is and how to address it.\n\nDocker has complicated relationship with user/group permissions on its \"volume\"\ndirectories, which exist on host, but need to be accessible to its containers,\nwith user/group values (or uid/gid - same thing for the purposes of this document)\nthat are configured in those, and don't match users/groups configured on host.\n\nComplicating matters further, docker can be configured to use uid/gid\nnamespacing mode (\"[userns-remap]\"), which makes container see different\nuid/gid values than host system, i.e. uid=123 inside container can be uid=2498479\non the host system where your shell is and where you actually see it.\n\nrdircd runs with default uid/gid either specified in [Dockerfile] (set via\nUID=55373 and GID=55373 lines there currently), or can be set manually to\nsomething else, either in that Dockerfile, or also via `args: [UID=..., GID=...]`\nline in [docker-compose.yml].\n\nAgain, note that those are uid/gid values *inside* the container, which can be\ndifferent on host system if something like userns-remap mode is enabled in\ndocker/podman/etc.\nAnd it might be enabled there for distro/setup or by default in the future.\n\nrdircd in this docker configuration needs its volume directory to be writable,\nto create and change files in there.\n\n[docker-compose.yml] file has two examples for how to specify rdircd\nconfig files volume, depending on which fix for the issue above can be\nslightly different - see either of the first two sections below for each:\n\n- [With default `config:/config` volume spec]\n- [When using e.g `./conf:/config` local directory]\n\nCommon workaround for this quirk in docker containers is to run entrypoint\nwrapper script as root, which will chown/chmod volumes as necessary,\nthen drop privileges for running the actual app, which has its own problems\n(like granting root privileges to anything in a container) and doesn't\nwork for userns-remapping case anyhow, so is not used here.\n\nThis is written as of early 2024 with docker 24.0.x in mind, so it's possible\nthat all this is handled better by other container runtimes (e.g. [podman])\nand especially future versions of those, with e.g. uid/gid remapping done on\noverlayfs level, so maybe also check for more modern solutions for such issues.\n\n[docker-compose.yml]: docker-compose.yml\n[Dockerfile]: Dockerfile\n[With default `config:/config` volume spec]: #hdr-if_you_re_using_default_volume_spec_in_d.9MBw\n[When using e.g `./conf:/config` local directory]: #hdr-when_using_local_directory_instead_of_ab.ioHM\n[podman]: https://podman.io/\n\n\n\u003ca name=hdr-if_you_re_using_default_volume_spec_in_d.9MBw\u003e\u003c/a\u003e\n## If you're using default `config:/config` volume spec in docker-compose.yml\n\nThen that \"named docker volume\" *should* be created by docker with correct\nuid/gid set for the container on first `docker-compose up` invocation.\n\nThen if you change these uid/gid values after that volume is already created,\nit **won't** change permissions on this volume, so either:\n\n- Don't change container uid/gid after creating the volume.\n- If there's no valuable data stored there, use `docker-compose down -v` to\n  remove volumes, so it'd re-create those from scratch with correct new uid/gid.\n- Run \"chown\" on the volume directory on the host system to correct uid/gid.\n\nIf there's no userns-remap'ping involved, last option (chown to new uid/gid),\nafter a failed `docker-compose up`, can be done like this:\n\n```\n% docker-compose run -u root --entrypoint sh rdircd \\\n    -c 'chown root:rdircd . \u0026\u0026 chmod 770 . \u0026\u0026 ls -lah .'\n\ntotal 23K\ndrwxrwx---    2 root     rdircd      3.4K May 24 10:05 .\ndrwxr-xr-x    1 root     root        3.4K May 24 10:05 ..\n-rw-------    1 rdircd   rdircd     14.4K May 24 10:05 config.ini\n```\n\n(`root:rdircd` and mode=770 there is so that rdircd user doesn't have access to\nchanging permissions and other metadata on the volume dir itself, and can only\nmanage stuff under it)\n\nIf userns remapping is enabled, command above shouldn't work (with \"permission\ndenied\" or such error), and you might need to use \"chown\" and \"chmod\" commands\nfrom the host system instead.\n\nSee [userns-remap] documentation for more details, but quick-and-dirty way to see\nwhat's the uid/gid on the host in such case and do the chmod/chown like above,\ncan be something like this:\n\n```\nuser% docker-compose run -u root --entrypoint sleep rdircd infinity\n\nroot# ps -o uid= $(pgrep -f 'sleep infinity')\n2498479\n\nroot# docker volume inspect -f '{{.Mountpoint}}' rdircd_config\n/var/lib/docker/volumes/rdircd_config/_data\n\nroot# chown root:2498479 /var/lib/docker/volumes/rdircd_config/_data\nroot# chmod 770 /var/lib/docker/volumes/rdircd_config/_data\n\nroot# pkill -9 -f 'sleep infinity'\n```\n\nMaybe there's some special docker command to do this stuff easier, idk.\n\n[userns-remap]: https://docs.docker.com/engine/security/userns-remap/\n\n\n\u003ca name=hdr-when_using_local_directory_instead_of_ab.ioHM\u003e\u003c/a\u003e\n## When using local directory instead of above, e.g `./conf:/config` in docker-compose.yml\n\nThen this \"conf\" directory under current dir (where you run docker-compose command)\ncan either exist already or will be auto-created by docker-compose.\n\nAt least as of docker 24.0.x, it will always be auto-created with incorrect\npermissions - \"root\" uid/gid and default 755 mode, i.e. always inaccessible\nfor writing to a container.\n\nSimple fix is to just chown/chmod that dir to correct permissions (with sudo or root),\ne.g. when using default uid/gid of 55373 from [Dockerfile] and no userns-remapping:\n\n```\n# mkdir -p conf \u0026\u0026 chown -R 55373:55373 conf\n# chown root:55373 conf \u0026\u0026 chmod 770 conf\n```\n\n(same as in other example above `root:55373` and mode=770 are so that rdircd\nuser doesn't have access to changing permissions and other metadata on the\nvolume dir itself, and can only manage stuff under it)\n\nIf uid/gid in docker configuration change, run above commands with new container\ngid on it - should work fine with the new host/configuration after that.\n\nEnabled [userns-remap] (or similar feature in other OCI runtimes) only\ncomplicates this by needing to use different uid/gid in chown command,\nthan one specified in the Dockerfile or docker-compose.yml.\n\nSimilar to previous section, I'd probably determine it via something like this:\n\n```\n% docker-compose run -u root --entrypoint sleep rdircd infinity\n% ps -o uid= $(pgrep -f 'sleep infinity')\n2498479\n```\n\nI.e. run \"sleep infinity\" in a container, then check what is its uid on the host\nsystem, and use that with chown/chmod commands from example above.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmk-fg%2Freliable-discord-client-irc-daemon","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmk-fg%2Freliable-discord-client-irc-daemon","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmk-fg%2Freliable-discord-client-irc-daemon/lists"}