Support rootless (backwards compatible) by simonfelding · Pull Request #110 · shenxn/protonmail-bridge-docker

simonfelding · 2024-12-06T11:28:39Z

Running as root is now optional.

…ing works

simonfelding · 2024-12-06T12:49:35Z

the fake terminal is not compatible with rootless, and isn't necessary anymore - i tested it.

simonfelding · 2024-12-06T13:05:07Z

closes #69 and #64

simonfelding · 2024-12-06T13:25:47Z

the containers are available here https://github.com/simonfelding/protonmail-bridge-docker/pkgs/container/protonmail

…lized properly.

yo8192 · 2025-02-18T16:53:05Z

Thanks for working on this. Will you also update the README (and maybe docker-compose.yml) to show how to run it as non-root?

ptrsr · 2025-03-16T18:21:55Z

Hi there, this PR is quite important as currently the auto update mechanism breaks existing containers. This PR has been open for 3 months now, is there anything that must be done for this to be merged?

Testing? Documentation? I'd love to help out.

simonfelding · 2025-04-24T18:35:16Z

Hey @ptrsr @yo8192 @xbc5 it would be great if you could help me test this out. I'll get a container built with this patch, and then you can test if it works as expected. Feel free to make a patch for documentation too, if you feel like it. Otherwise I'll get to it eventually.

ptrsr · 2025-04-25T09:26:53Z

I'll take a look this weekend, thanks!

yo8192

Built with:

$ docker buildx build --build-arg version=$(cat ../VERSION) -t protonmail-bridge:$(cat ../VERSION)_pr110

Then I ran with a previously initialized volume, which had its content owned by user UID/GID 8535:

$ docker stop protonmail-bridge ; docker rm protonmail-bridge ; docker run --user 8535:8535 -d --name=protonmail-bridge -v protonmail:/home/protonmail -e HOME=/home/protonmail -p 127.0.0.1:1025:2025/tcp -p 127.0.0.1:1143:2143/tcp --restart=unless-stopped protonmail-bridge:v3.19.0_pr110

That worked fine.

I did see this warning in the container logs:

WARN[May  3 18:37:31.911] Failed to add test credentials to keychain    error="failed to open dbus connection: exec: \"dbus-launch\": executable file not found in $PATH" helper="*keychain.SecretServiceDBusHelper"

but that doesn't seem to prevent the bridge from working.

yo8192 · 2025-05-03T15:46:58Z

+    # give friendly error if the user doesn't own the data
+    if [[ $(id -u) != 0 ]]; then
+        if [[ `find $HOME/.* -not -user $(id -u) | wc -l` != 0 ]]; then
+          echo "You do not own the data in $HOME. Please chown it to $(id -u), run the container as the owner of the data or run the container as root."


How about: "You do not own some or all of the data in $HOME" and "recursively chown it"

Right, that's better.

yo8192 · 2025-05-03T15:52:04Z

+    fi
+
+    # delete lock files if they exist - this can happen if the container is restarted forcefully
+    find $HOME -name "*.lock" -delete


there might be a chance of two containers mounting the same filesystems, and the other one still running?
It might make sense to ask the user to confirm before deleting, or print a message telling them what to do instead of silently deleting?

Good point. Can you help with a contribution for this?

Sure:

Suggested change

find $HOME -name "*.lock" -delete

mapfile -t lockfiles < <(find $HOME -name "*.lock" )

if [ ${#lockfiles[@]} -gt 0 ]; then

echo "WARNING: found ${#lockfiles[@]} lock file(s): ${lockfiles[@]}"

echo " Make sure no other container proton-bridge are running (e.g. in another container)."

read -p " Press Y to delete the lockfiles and continue, or anything else to abort: " REPLY

if [ "$REPLY" = Y ]; then

# Quote all filenames for safety, e.g. in case of spaces in filenames:

for LOCKFILE in "${lockfiles[@]}" ; do

rm "$LOCKFILE"

done

else

echo "user aborted."

exit 1

fi

fi

I'm quite interested in a rootless setup for that container, so @simonfelding if you could review the changes it would make it easier for users to just checkout that PR instead of having to do the diffs :)

I believe the "Y" should be case insensitive during that prompt, would be a bit better

Actually I can't use docker compose up because it prompts me for a Y so I believe we should add an env var to enable automatically deleting lockfiles

thiswillbeyourgithub · 2025-06-17T09:27:23Z

 FROM debian:sid-slim
 LABEL maintainer="Simon Felding <sife@adm.ku.dk>"

+# These are only exported if running as root


Not sure "exported" is the correct word. Maybe you meant "used"?

thiswillbeyourgithub · 2025-06-17T09:45:40Z

+
+# give friendly error if you don't have protonmail data
+if [[ `find $HOME | wc -l` == 1 ]]; then # 1 because find $HOME will always return $HOME
+    echo 'Protonmail does not seem to have been initialized yet. Enter the container with something like `docker exec -it <container_name>` and type "help" for instructions on how to set up the ProtonMail Bridge'


Not clear. I suggest this:

echo 'Protonmail does not seem to have been initialized yet. For instructions on how to set up the ProtonMail Bridge, enter the container with something like `docker exec -it protonmail-bridge help` or `docker compose run protonmail-bridge help`'

Edit: oh you meant to type help in the console right? For some reason the --cli help just showed the man page in the docker logs so maybe the bridge's cli changed with updates or something?

Wouldn't it be better to use expect to automatically add the add inside the console? We could even use docker secrets to store the protonmail account info just during the init.

thiswillbeyourgithub · 2025-06-17T10:00:41Z

+echo "Starting ProtonMail Bridge. Connect to the CLI with `docker exec -it <container_name>` and type 'help' for instructions."
+/protonmail/proton-bridge --cli $@
+echo "ProtonMail bridge stopped. waiting 30 seconds before exiting in order to preserve the logs."
+sleep 30 # so we have time to read the logs in case of a crash loop


Wouldn't it be better to delete any remaining lock files at the end of that script too? For some reason the bridge seems to not clean those sometimes for me. But in any case at the last line of the entrypoint any remaining lock file has to have been forgotten and can be deleted safely no?

thiswillbeyourgithub · 2025-06-17T10:06:22Z

Wouldn't it be better to use a read only filesystem and drop all capabilities? That would increase security

thiswillbeyourgithub · 2025-06-17T10:08:42Z

+| .Settings.Autostart = false
+| .Settings.SMTPPort = 1025
+| .Settings.IMAPPort = 1143 ' \
+| /protonmail/vault-editor write


Is that future proof? I believe using expect to specify the ports, disabling telemetry etc would be way better as the user facing shell has less chance of suffering breaking changes than the internal proton bridge json.

thiswillbeyourgithub · 2025-06-17T10:54:47Z

Btw there is proton-bridge --noninteractive that can be called at the end to wait forever without having to use the --cli argument.

yo8192 · 2025-08-26T13:22:45Z

I tried again, from scratch this time, and an issue is that the volume gets mounted with the permission of the directory you mount it on in the container.
So if I mount it on /data which didn't exist already, this ends up being owned by root, so not writable by the non-root user.

To fix this, it looks like creating /data as a tmp folder works:

RUN mkdir -m 1777 /data

That does mean 'forcing' to mount on /data when running as non-root, but hopefully ok?

yo8192 · 2025-08-26T13:26:15Z

+# give friendly error if you don't have protonmail data
+if [[ `find $HOME | wc -l` == 1 ]]; then # 1 because find $HOME will always return $HOME
+    echo 'Protonmail does not seem to have been initialized yet. Enter the container with something like `docker exec -it <container_name>` and type "help" for instructions on how to set up the ProtonMail Bridge'
+    timeout 10s /protonmail/proton-bridge --noninteractive # this starts the bridge in non-interactive mode and kills it after 20 seconds, so we can populate the vault with default values and override them with the env variables in the later step.


this exists with an error for me when running as non-root on a new volume:

ERRO[Aug 26 12:50:29.816] Could not load/create vault key error="could not create keychain: no keychain" ERRO[Aug 26 12:50:30.080] Failed to migrate old accounts error="failed to create keychain: no keychain" WARN[Aug 26 12:50:30.085] The vault key could not be retrieved; the vault will not be encrypted

As you have set -e, entrypoint.sh exits, i.e. the container fails.

Replacing this with timeout 10s /protonmail/proton-bridge --noninteractive || /bin/true is a hacky way to avoid entrypoint.sh to stop there.

yo8192 · 2025-10-18T17:18:54Z

+fi

-    # Initialize pass
+if [[ ! -f $HOME/.gnupg ]]; then


this should be -d (as opposed to -f) because .gnupg is a directory.

simonfelding added 3 commits December 5, 2024 22:19

debian supports riscv64 now so we can just switch to that and everyth…

b3c8d67

…ing works

add (backwards compatible) support for running rootless

db779f4

fix restarts

ac55256

update deb entrypoint

5368a23

simonfelding added 12 commits December 6, 2024 14:43

add friendly error messages for when the container hasn't been initia…

b62e016

…lized properly.

slightly nicer find commands

e117b46

fix find

2fc6d54

fix entrypoint

a7c8aee

slight entrypoint enhancements for debugging purposes

51a8142

increase readability

045c7bb

add building the vault editor for protomailv3

166a822

add ps utils

b874fa9

add env variables!

18040d4

disable the vault-editor stuff because it is currently broken.

037bc21

test

97ae2ee

fix settings updater

7f15c4b

This was referenced Feb 15, 2025

Run as a non-root user #69

Open

Telemetry is enabled by default #107

Open

Auto-update mechanism causing arm64 version to not start if newer amd64 version available publicly #113

Open

protonmail-bridge auto updates without consent #106

Closed

simonfelding added this to the Run the container in rootless mode milestone Feb 15, 2025

simonfelding added 3 commits April 24, 2025 20:36

Merge branch 'master' into support-rootless

3e0cc0f

build pr images too

a7fcf0f

push test images to ghcr.io/shenxn/protonmail-bridge-dev

6e7290e

simonfelding added 4 commits April 24, 2025 23:49

Merge branch 'master' into support-rootless

ef7ba0b

fix space

a68521b

fix pr builds

cb2cf75

Merge branch 'shenxn:master' into support-rootless

4e5d190

yo8192 approved these changes May 3, 2025

View reviewed changes

Repository owner deleted a comment from yo8192 May 27, 2025

simonfelding added 3 commits June 12, 2025 16:49

simplified some stuff. it should work now!

651cbbd

fix missing if statement closing

7ef9657

there we go.

d483aa1

thiswillbeyourgithub mentioned this pull request Jun 17, 2025

Security: don't run the container from root #123

Closed

thiswillbeyourgithub reviewed Jun 17, 2025

View reviewed changes

yo8192 reviewed Aug 26, 2025

View reviewed changes

yo8192 reviewed Oct 18, 2025

View reviewed changes

SilentSpud added a commit to SilentSpud/protonmail-bridge-docker that referenced this pull request Dec 22, 2025

Almost working expect script based on the notes from shenxn#110

fb25e05

IllusoryKitsune mentioned this pull request Apr 15, 2026

Fix failing multi-arch runs; sync reliability fixes from upstream IllusoryKitsune/protonmail-bridge-docker#2

Merged

4 tasks

-    find $HOME -name "*.lock" -delete
+    mapfile -t lockfiles < <(find $HOME -name "*.lock" )
+    if [ ${#lockfiles[@]} -gt 0 ]; then
+        echo "WARNING: found ${#lockfiles[@]} lock file(s): ${lockfiles[@]}"
+        echo "  Make sure no other container proton-bridge are running (e.g. in another container)."
+        read -p "  Press Y to delete the lockfiles and continue, or anything else to abort: " REPLY
+        if [ "$REPLY" = Y ]; then
+            # Quote all filenames for safety, e.g. in case of spaces in filenames:
+            for LOCKFILE in "${lockfiles[@]}" ; do
+                rm "$LOCKFILE"
+            done
+        else
+            echo "user aborted."
+            exit 1
+        fi
+    fi

Uh oh!

Conversation

simonfelding commented Dec 6, 2024

Uh oh!

simonfelding commented Dec 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

simonfelding commented Dec 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

simonfelding commented Dec 6, 2024

Uh oh!

yo8192 commented Feb 18, 2025

Uh oh!

ptrsr commented Mar 16, 2025

Uh oh!

simonfelding commented Apr 24, 2025

Uh oh!

ptrsr commented Apr 25, 2025

Uh oh!

yo8192 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thiswillbeyourgithub Jun 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thiswillbeyourgithub Jun 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thiswillbeyourgithub commented Jun 17, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thiswillbeyourgithub commented Jun 17, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

simonfelding commented Dec 6, 2024 •

edited

Loading

simonfelding commented Dec 6, 2024 •

edited

Loading

thiswillbeyourgithub Jun 17, 2025 •

edited

Loading

thiswillbeyourgithub Jun 17, 2025 •

edited

Loading