mirror of
https://github.com/axllent/mailpit.git
synced 2026-04-26 00:35:51 +03:00
[GH-ISSUE #281] Failure to start using environment variables #186
Labels
No labels
awaiting feedback
bug
docker
documentation
enhancement
github_actions
invalid
pull-request
question
stale
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mailpit#186
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jreydep on GitHub (Apr 20, 2024).
Original GitHub issue: https://github.com/axllent/mailpit/issues/281
I am trying to make a enviroment file when Mailpit is being started as service and I can use any variable inside without problem, but the moment I put in a certificate the start fails. The same env configuration but passed through flags works perfectly.
I no longer know if I am doing something wrong or if there is something in the file that is wrong. This is part of the file I have in "/etc/systemd/system/mailpit.service.d/override.conf"
@axllent commented on GitHub (Apr 20, 2024):
@jreydep I think I can see what is going on here - are you starting Mailpit via systemd as a non-privileged user (ie: not root), but are testing manually with the same environment variables as root? In your example,
/etc/ssl/private/ssl-cert-snakeoil.keyis only readable as root.Can you please confirm this for me?
@jreydep commented on GitHub (Apr 20, 2024):
Yes, that was the problem... another case of rubber duck. I started thinking the same thing a while ago and when in the .service I changed the user to root and it worked, I realized the permissions issue.
Sorry to respond late, I had taken the opportunity to have dinner and regain my mental health. Changing User and Group from mailpit to root allows the script to start without problems.
@axllent commented on GitHub (Apr 20, 2024):
Glad to hear you found the cause. Just to clarify, you can easily run Mailpit as an unprivileged user provided:
I've made a code change to help users understand the permissions issue you faced (rather than a complicated "panic" message) - which will make it's way into the next release. It will basically display a human-friendly manner that the file does not exist or they don't have permission to read it.