Hi Timo, 2025.December 2.(K) 12:25 időpontban Timo Sirainen via dovecot ezt írta: > On 2. Dec 2025, at 11.41, Tóth Attila via dovecot <[email protected]> > wrote: >> While 2.3 created files/directories in the name of the current user >> under >> ~/mail, 2.4 tries to write as mail:mail and therefore gets denied, since >> the user directories are owned by username:users and obviously have no >> permissions for other users. > > The change of user/group not about mail/mbox configuration. It is about > userdb configuration or perhaps mail_uid / mail_gid settings. There are no > default changes related to them, so I guess you somehow configured them > differently in v2.4.
In both versions mail_uid and mail_gid were set to mail and mail at different locations of the configuration files. default_internal_user was set to dovecot, therefore some processes (anvil, stats) were running as dovecot. default_login_user was dovenull and the auth worker accessed shadow as root. I've also configured first_valid_user & last_valid_user and first_valid_gid & last_valid_gid to a relevant range. That was the reason I first noticed it tries to write as mail:mail in users home directories. After removing this restriction the software faced with a permission problem. Note that there are also questionably relevant settings: 1. mail_privilged_group # System user and group used to access mails. If you use multiple, userdb # can override these by returning uid or gid fields. You can use either numbers # or names. <doc/wiki/UserIds.txt> 2. mail_access_groups # Group to enable temporarily for privileged operations. Currently this is # used only with INBOX when either its initial creation or dotlocking fails. # Typically this is set to "mail" to give access to /var/mail. and 3. mail_full_filesystem_access # Grant access to these supplementary groups for mail processes. Typically # these are used to set up access to shared mailboxes. Note that it may be # dangerous to set these if users can create symlinks (e.g. if "mail" group is # set here, ln -s /var/mail ~/mail/var could allow a user to delete others' # mailboxes, or ln -s /secret/shared/box ~/mail/mybox would allow reading it). Neither of these seem to influence the gid&uid dovecot tries perform write operations in users homedirs. mail_uid and mail_gid didn't represent the way it was operating before. I didn't want to change that to any particular users gid or uid, because that should be separately applicable to each individual user. So how I would make v2.4 dovecot writing in users home directories using the respective users uid&gid like before and not as mail_uid and mail_gid? Is there a configuration option now for v2.4 I'm not aware of or what?? Thanks: Dwokfur -- dr Tóth Attila, Radiológus, 06-20-825-8057 Attila Toth MD, Radiologist, +36-20-825-8057 > > _______________________________________________ > dovecot mailing list -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
