Procmail error 73 Fedora 38 Beta

Ask Fedora
,
1

How can I solve this?

2023-03-28T15:15:29-0300 tars crond[89450]: procmail: Couldn't create "/var/spool/mail/marcelo"
2023-03-28T15:15:29-0300 tars crond[89449]: MDA returned nonzero status 73
2023-03-28T15:15:33-0300 tars crond[89454]: procmail: Couldn't create "/var/spool/mail/marcelo"
2023-03-28T15:15:33-0300 tars crond[89453]: MDA returned nonzero status 73

I enabled some backup scripts via crontab -e, and it looks like it started when I did it. Now I commented everything, but it keeps going. Removed my user’s crontab file; restored it; created and empty one…

2

It seems the problem isn’t with cron firing, but that procmail couldn’t create the mailbox for the user:

/var/spool/mail/marcelo

It’s likely that either the procmail process user can’t write to /var/spool/mail or is blocked from doing so by SELinux. Do you see any AVC denials in journalctl around this time related to procmail?

3

Cron was firing with no problems, just one command I misstype and decide to check the logs and found those messages.
journalctl | grep AVC found nothing. As is an upgrade from F37 I ran the Post-upgrade option commands, one of them is related to SELinux.

4

Permissions on this directory only allow write access for root.
The mailbox should have been created automatically along with the user’s home directory.
Since it no longer exists, you can restore it manually like this:

sudo touch /var/spool/mail/${USER}
sudo chown ${USER}:mail /var/spool/mail/${USER}
sudo chmod ug=rw,o= /var/spool/mail/${USER}
1 Like
5

I already tried similarly creating a new file and copying the permissions with no luck. Also tried yours and got the same result.

6

Since procmail wants to create the file, we can assume it does not exist.
And if the file is actually missing, then you need to investigate how it was removed.

I hope you are not confusing /var/spool/cron and /var/spool/mail.
The former is for crontabs and the latter is for mailboxes.

If you want to remove own crontab, use this:

crontab -r

Be sure to apply changes:

sudo systemctl restart crond.service
1 Like
7

The file is there. Not removed. Was there when I first saw those log messages. I removed after and tried to create a new one with the same permissions, but got the same messages.

doas lsd -thral /var/spool/mail/$USER
.rw-rw---- marcelo mail 0 B Wed Mar 29 12:57:33 2023  /var/spool/mail/marcelo
1 Like
8

Mucking about with system installed files is seldom fruitful and often breaks things.
SELinux may be interfering now and that can be fixed with sudo restorecon -R /var/spool. By temporarily disabling selinux with sudo setenforce 0 while testing you may find out if it is caused by selinux.

The permissions should be (by default)

# ls -lZ /var/spool/mail
total 0
-rw-rw----. 1 $USER mail system_u:object_r:mail_spool_t:s0 0 Mar 10 20:09 $USER

(note that I obfuscated my user id)

9

No change. the root is also like that and I didn’t even touch it.

❯ doas setenforce 0
setenforce: SELinux is disabled
❯ doas restorecon -v -R /var/spool
❯ doas ls -lZ /var/spool/mail
total 36
-rw-rw----  1 marcelo mail ?                                     0 mar 29 12:57 marcelo
-rw-------  1 root    root ?                                 34730 mar 15 12:05 root
-rw-rw----. 1 rpc     mail system_u:object_r:mail_spool_t:s0     0 mar  9  2022 rpc
❯ grep -o "selinux=1" /proc/cmdline
selinux=1
10

Did restorecon give you any messages?

This tells you the selinux context is not set for those files. I would expect that procmail is being prevented from writing there.
What is the result of ls -lZd /var/spool/mail

# ls -lZd /var/spool/mail
drwxrwxr-x. 2 root mail system_u:object_r:mail_spool_t:s0 4096 Mar 10 20:09 /var/spool/mail
2 Likes
11

My previous post is the copy of what was shown to me, restorecon showed nothing.

12 
getenforce; sestatus; sudo semanage export
1 Like
13

Weird!

❯ doas getenforce; sestatus; doas semanage export 
Disabled
SELinux status:                 disabled
boolean -D
login -D
interface -D
user -D
port -D
node -D
fcontext -D
module -D
ibendport -D
ibpkey -D
permissive -D
boolean -m -1 selinuxuser_execmod
boolean -m -1 virt_sandbox_use_all_caps
boolean -m -1 virt_use_nfs

Could be a F38 Beta bug?

1 Like
14 
grep -v -e "^#" -e "^$" /etc/selinux/config
1 Like
15 
grep -v -e ^# -e ^$ /etc/selinux/config
SELINUX=disabled
SELINUXTYPE=targeted
1 Like
17

Previous post was the content of the directory. My last request was for the actual directory listing.

Just to add a bit of explanation to the post by Vladislav above.
When SELinux is disabled it does not do anything. Files created are not given an selinux content, nothing is checked to allow or restrict access, etc. Those files you posted with no context are possibly a very small percentage of the total files in the system that might not have an selinux context assigned.
The commands given will put selinux into enforcing mode and then relabel all the system files with the proper context during the reboot.

Also, when you ran restorecon with selinux disabled it had nothing to do (it was disabled) so could not tell you what it did.

2 Likes
18

Thanks for everything. I decided to do a fresh install.

Something was wrong. The selinux=1 line inside /etc/default/grub is not present on a fresh F38, it was inherited from previous installation and not corrected during the upgrade(s). As I had also various problems before and after upgrading with constant packages conflicts, restoring my snapshots or a fresh install were better options than digging it further.

1 Like