Container crashes / won't start: "No module named 'mailrise'"

[MadKillerChicken]

Hi there, and thanks for this great project BTW.

I'm having a strange issue that I've never seen before (not that experienced in the container business).
Container appears to start on startup with the following log output:

2023-03-03 18:07:48.899607+00:00 File "/home/mailrise/.local/bin/mailrise", line 5, in <module>
2023-03-03 18:07:48.899628+00:00 from mailrise.skeleton import run
2023-03-03 18:07:48.899638+00:00 ModuleNotFoundError: No module named 'mailrise'

Followed the docs, mounted a config file, tried latest and stable variants.
Not sure if I'm missing something here, sounds python, not container related though, any ideas?

[YoRyan]

That's really strange. Could I see your full Docker command line?

Are you able to run the container with the bare minimum of arguments?

$ docker run -it --rm yoryan/mailrise --help
usage: mailrise [-h] [--version] [-v] [-vv] CONFIG

An SMTP gateway for Apprise notifications

positional arguments:
  CONFIG               path to configuration file

options:
  -h, --help           show this help message and exit
  --version            show program's version number and exit
  -v, --verbose        set loglevel to INFO
  -vv, --very-verbose  set loglevel to DEBUG

[MadKillerChicken]

You're obviously right, what I said makes little sense.

Anyway, the only place where user related settings seem to be getting set are called runAsUser, runAsGroup and fsGroup (marked green in the screenshots). All of these are set to the custom user I mentioned earlier, but that's a host OS user. Especially fsGroup is used to allow FileSystem access to the config file on the host. The other two settings define the user, that'll be running the pod on the host, I think.

The settings marks in red were disabled, I enabled them to show you all the available security related settings.

I excluded all remaining settings, as they didn't seem relevant (network related and so on).

Please note that setting "runAsNonRoot" doesn't seem to have any effect on this issue.

[abpei]

I've gotten a few reports from Unraid users about strange Python errors, too. We were eventually able to figure out that Unraid supports directory passthrough but not file passthrough, which is what the image uses by default. So when these users tried to passthrough their /etc/mailrise.conf files, they ended up overriding their entire /etc directory and breaking the Python executable.

I don't entirely understand the error you're getting, but it could be a similar case. Are you willing to share a screenshot of your container configuration?

can confirm, had the same issue with portainer. binding the config file only instead of mapping the entire directory as volume fixed it. thanks for this.

[YoRyan]

Anyway, the only place where user related settings seem to be getting set are called runAsUser, runAsGroup and fsGroup (marked green in the screenshots). All of these are set to the custom user I mentioned earlier, but that's a host OS user. Especially fsGroup is used to allow FileSystem access to the config file on the host. The other two settings define the user, that'll be running the pod on the host, I think.

Apologies for the long delay—this thread got buried in my notifications. Try 999 for both the user and group. That's the user the container was intended to run as.

[Hinni79]

Thank you, thank you, thank you - this mention of 999 finally made the container run on my QNAP NAS. It seems Container Station tries to run as root by default. When using user "mailrise", I wasn't able to access /etc/mailrise.conf. When telling the container to go with user 1000 (my admin user on QNAP), the above python error appeared.

Finally a simple "sudo chown 999:999 mailrise.conf" on the QNAP made the container launch (doesn't matter I have no user with that ID on the NAS). Now I have to figure out, if it works, but at least it does not terminate after a few seconds.

[Qhilm]

As a note, GUID '999' is the group 'synopkgs' on DSM 7 (Synology) machines. Not entirely sure how big a security problem that might be.