Permission problems

[kroese]

On the Alpine image I see these messages:

2024-01-08T07:08:37.820982+01:00 WARNING postfix/postfix-script[273]: warning: not owned by postfix: /var/lib/postfix/./master.lock
2024-01-08T07:08:37.829202+01:00 WARNING postfix/postfix-script[281]: warning: not owned by group postdrop: /usr/sbin/postqueue
2024-01-08T07:08:37.832658+01:00 WARNING postfix/postfix-script[282]: warning: not owned by group postdrop: /usr/sbin/postdrop
2024-01-08T07:08:37.836698+01:00 WARNING postfix/postfix-script[284]: warning: not set-gid or not owner+group+world executable: /usr/sbin/postqueue
2024-01-08T07:08:37.840141+01:00 WARNING postfix/postfix-script[285]: warning: not set-gid or not owner+group+world executable: /usr/sbin/postdrop
2024-01-08T07:08:37.844777+01:00 INFO    postfix/postfix-script[287]: starting the Postfix mail system
2024-01-08T07:08:37.848836+01:00 CRIT    postfix/master[288]: fatal: open lock file /var/lib/postfix/master.lock: cannot open file: Permission denied
2024-01-08 07:08:38,849 WARN exited: postfix (exit status 1; not expected)

Even if I delete all the Postfix folders and let them be created from scratch, these errors don't go away.

What could be causing this?

[bokysan]

Which version are you running? How are you running the image? Are you using any mounted directories? Do you have SKIP_ROOT_SPOOL_CHOWN set?

[kroese]

The latest (latest-alpine) ARM64 version, sha256:15cb222cf4b8472b1416d7bfcdc97d9eaceb287e3807545504e62d37595fb9e3

I also run it on a AMD64 server, and there I dont see this problem, so it might be possible it only happens on ARM.

The composefile is identical on both systems:

postfix:
    hostname: postfix  
    container_name: postfix
    image: "boky/postfix:latest-alpine"
    environment:
      - "HOSTNAME=XXX"   
      - "TZ=Europe/Amsterdam"
      - "MYNETWORKS=0.0.0.0/0,[::]/0"
      - "ALLOW_EMPTY_SENDER_DOMAINS=true"
      - "RELAYHOST=XXX"
      - "RELAYHOST_USERNAME=XXX"
      - "RELAYHOST_PASSWORD=XXX"
    volumes:
      - "/mnt/data/postfix/etc:/etc/postfix"
      - "/mnt/data/postfix/keys:/etc/opendkim/keys"
      - "/mnt/data/postfix/spool:/var/spool/postfix"      
    ports:
      - 25:25
    networks:
      - web
    dns_search: .
    restart: always
    stop_grace_period: 2m

As you can see I have no SKIP_ROOT_SPOOL_CHOWN set. And this compose file always worked until yesterday when I updated to the new image.

[kroese]

I reverted back to v4.0.2-alpine and it works without any permission problems.

So I am positive this regression in the ARM image was introduced recently. I was especially following latest instead of edge to avoid problems like this.

[bokysan]

This is really odd, as there were no changes that would cause this issue.

Are you running into this issue with v4.1.0 as well?

[kroese]

I just tried and v4.1.0 also works fine.

[bokysan]

Odd. But since v4.1.0 works I think we can close this ticket. I'd still like to know what caused it, though, to avoid repeats. So if you run into any additional information, please do reopen it.

[bokysan]

That is in fact the case, but how is your /tmp/ not writtable?

[kroese]

I figured out what happened and it had nothing to do with your code, sorry.

I copied my /var/lib/docker to another partition using sudo. I should have used a flag to preserve the owner permissions in hindsight, because now all files became owned by root. At first it seemed everything worked okay, but there is an overlay2 folder that keeps the diff for images when a container modifies the files within a container. The result was that certain directories (like \tmp and \var\lib\postfix) now became owned by root inside the image.

I did not realize the problem was on my end, because when I switched between versions of your image the problem disappeared. But this was because the layers of the image are cached in overlay2, so when I tried an image that did not exist previously I got the correct permissions.

So sorry for bothering you. At least now you know that there is a situation in which the permissions inside the container can be different as what is specified in Dockerfile, but it's really an edge case that will not occur under normal usage, so it's not necessary to handle that in your script.