Mailcow dockerized - Dovecot permission denied Fehler nach Update?

26z_sdf4h54785

Hallo liebe Community,
ich habe vor einigen Tagen meinen Mailcow Testserver aktualisiert (per sh File) - nun scheint mein Speicherpfad für die Mails nicht mehr funktionieren zu wollen.

Folgendes konnte ich im Logfile sehen:

imap(x@x)<142><X>: Error: Mailbox Drafts: rename(/var/vmail/x/x/Maildir/.Drafts/dovecot-uidlist.tmp, /var/vmail/x/x/Maildir/.Drafts/dovecot-uidlist) failed: Permission denied

imap(x@x)<481><x>: Error: Mailbox Drafts: rename(/var/vmail/x/x/Maildir/.Drafts/dovecot-uidlist.tmp, /var/vmail/x/x/Maildir/.Drafts/dovecot-uidlist) failed: Permission denied

Zur Konfiguration:
Beim vmail Pfad handelt es sich um einen Share der in /etc/fstab gemounted wird - habe es auf beide der verlinkten Möglichkeiten (override.yml und link gemäss hier) versucht aber es kommt die gleiche Fehlermeldung.

Die erstellten Folders und Files im Directory gehören root.

Vielen Dank für eure Ideen!

esackbauer

26z_sdf4h54785 Permission denied

Vielleicht nicht als root user das Update gemacht?

26z_sdf4h54785

Soweit mir ist geht das gar nicht? :-).

./update.sh
You need to be root

./update.sh
You need to be root

DocFraggle

Dann wird es wohl an Deinem von Hand gemounteten vmail Verzeichnis liegen. Hast Du denn da mal kontrolliert ob alles stimmt?

26z_sdf4h54785

Der mount im fstab:
//x/mailmount /mnt/mailcowdata cifs uid=0,credentials=/root/.smbmail,iocharset=utf8,vers=3.0,noperm 0 0

Ich kann im Directory als regulärer (und als root user) lesen und schreiben.

docker-compose.override.yml habe ich rausgenommen und per ln einen Link gemacht.

Vorher:

version: '2.1'
volumes:
  vmail-vol-1:
    driver_opts:
     type: none
     device: /mnt/mailcowdata/vmail
     o: bind

Jetzt:
lrwxrwxrwx 1 5000 5000 27 Mar 24 11:39 _data -> /mnt/mailcowdata/vmail_data

Und das Vereichnis im /mnt/maildcowdata:
drwxr-xr-x 2 root root 0 Apr 5 14:16 vmail_data

Muss das /mnt/ dir irgendwelche spezielle Rechte haben oder einem User gehören? In der Dokumentation (https://docs.mailcow.email/manual-guides/Dovecot/u_e-dovecot-vmail-volume/#the-old-way) steht nichts von dem.

DocFraggle

User und Gruppe von _data und unterhalb müssen aber 5000 sein

drwxr-xr-x 13 5000 5000 4096 Nov 4 15:54 _data

Bei Dir ist es root

26z_sdf4h54785

Hat früher so funktioniert (??) 🙂
In fstab geändert (uid=5000,guid=5000):
drwxr-xr-x 2 5000 5000 0 Apr 5 14:16 vmail_data

Aber geht immer noch nicht. Gleicher error

u.A. auch:

04/06/2025, 01:00:32 PM	crit	imap(x@x)<145><x>: Fatal: master: service(imap): child 145 killed with signal 6 (core dumped)
04/06/2025, 01:00:32 PM	crit	imap(x@x)<145><x>: Panic: file maildir-save.c: line 757 (maildir_save_sync_index): assertion failed: (first_uid != 0)

DocFraggle

Was ist denn mit den Unterverzeichnissen und Dateien? Hast Du alles auf 5000:5000 geändert/gecheckt?

26z_sdf4h54785

Ja, hatte einen chown 5000:5000 -R gemacht. Die Files sind alle so drin, soweit ich gesehen habe:

drwxr-xr-x 2 5000 5000  0 Apr  5 15:09 .Archive
drwxr-xr-x 2 5000 5000  0 Apr  6 13:02 .Drafts
drwxr-xr-x 2 5000 5000  0 Apr  6 12:59 .Sent
drwxr-xr-x 2 5000 5000  0 Apr  5 14:16 cur
-rwxr-xr-x 1 5000 5000  0 Apr  5 14:16 dovecot-acl-list
-rwxr-xr-x 1 5000 5000  0 Apr  5 14:16 maildirfolder
drwxr-xr-x 2 5000 5000  0 Apr  5 14:16 new
-rwxr-xr-x 1 5000 5000 25 Apr  5 14:48 subscriptions
drwxr-xr-x 2 5000 5000  0 Apr  5 14:16 tmp

DocFraggle

Und auch nochmal neu gestartet?

docker compose down
docker compose up -d

esackbauer

Ich bin mir nicht sicher ob CIFS eine gute Wahl ist für den mountpoint…
Wir hatten schon hier das Thema wo jemand versucht hat die mailcow auf einem S3 Filesystem zu hosten, das hat nicht geklappt weil das Filesystem nicht alle Features eines Linux-Filesystems hat das mailcow aber braucht.
Ich vermute dass hier durch Updates eine Inkompatilibität entstanden ist, und CIFS nicht mehr die erforderlichen Features richtig unterstützt.
Vielleicht kann man es auf NFS umbauen? Da wäre man wenigstens halbwegs in der Linux-Welt…

26z_sdf4h54785

Kurzer Update: Es scheint als währe effektiv SMB/CIFS das Problem - mit NFS funktioniert es einwandfrei! Vielen Dank!