Since upgrading to Kubuntu 24.04 I have been having problems with email storage using Thunderbird. Thunderbird is now installed as a Snap.
I store my emails on my local server so that I can access them from different computers and connect through my wired network.
I had a weird situation where sometimes on starting the computer Thunderbird connected OK to the server, but at other times it failed to access them. It took me a while to work out that if the computer was turned off over-night, the next day it would fail to access the mail on the server. On rebooting it accessed the mail on the server correctly.
I also have observed that if I turn the computer off, then a couple of hours later reboot, it again connects correctly.
It appears that the overnight shutdown is the catalyst for the connection issue.
I have now set Thunderbird to autostart on boot, but the problem was the same if I activated it manually after startup.
Others have reported online problems with setting a remote local directory using the new Thunderbird Snap on Kubuntu 24.04.
I also installed Thunderbird as a Flatpack to check if it was the Snap, and experienced exactly the same behavior with the Flatpack install.
I checked with dmesg and have found that after the overnight shutdown, the next day the last entries resulting from Thunderbird startup are as follows:
[ +2.096772] kauditd_printk_skb: 7 callbacks suppressed
[ +0.000005] audit: type=1107 audit(1726543014.112:261): pid=1538 uid=103 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/timedate1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.103" pid=2836 label="snap.thunderbird.thunderbird" peer_pid=3708 peer_label="unconfined"
exe="/usr/bin/dbus-daemon" sauid=103 hostname=? addr=? terminal=?'
[ +0.000916] audit: type=1107 audit(1726543014.113:262): pid=1538 uid=103 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/timedate1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.103" pid=2836 label="snap.thunderbird.thunderbird" peer_pid=3708 peer_label="unconfined"
exe="/usr/bin/dbus-daemon" sauid=103 hostname=? addr=? terminal=?'
[Sep17 13:18] audit: type=1107 audit(1726543127.777:263): pid=1538 uid=103 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/timedate1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.112" pid=2836 label="snap.thunderbird.thunderbird" peer_pid=4433 peer_label="unconfined"
exe="/usr/bin/dbus-daemon" sauid=103 hostname=? addr=? Terminal=?'
These messages do not appear after a reboot when the emails are correctly accessed.
Is this a timing issue with network connection of some sort after a long period shut down or is there some other explanation?
Is it that Thunderbird is called before the network connection to the server is established? I have established that it is not the server causing the problem as other users with Kubuntu 22.04 can connect correctly.
I store my emails on my local server so that I can access them from different computers and connect through my wired network.
I had a weird situation where sometimes on starting the computer Thunderbird connected OK to the server, but at other times it failed to access them. It took me a while to work out that if the computer was turned off over-night, the next day it would fail to access the mail on the server. On rebooting it accessed the mail on the server correctly.
I also have observed that if I turn the computer off, then a couple of hours later reboot, it again connects correctly.
It appears that the overnight shutdown is the catalyst for the connection issue.
I have now set Thunderbird to autostart on boot, but the problem was the same if I activated it manually after startup.
Others have reported online problems with setting a remote local directory using the new Thunderbird Snap on Kubuntu 24.04.
I also installed Thunderbird as a Flatpack to check if it was the Snap, and experienced exactly the same behavior with the Flatpack install.
I checked with dmesg and have found that after the overnight shutdown, the next day the last entries resulting from Thunderbird startup are as follows:
[ +2.096772] kauditd_printk_skb: 7 callbacks suppressed
[ +0.000005] audit: type=1107 audit(1726543014.112:261): pid=1538 uid=103 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/timedate1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.103" pid=2836 label="snap.thunderbird.thunderbird" peer_pid=3708 peer_label="unconfined"
exe="/usr/bin/dbus-daemon" sauid=103 hostname=? addr=? terminal=?'
[ +0.000916] audit: type=1107 audit(1726543014.113:262): pid=1538 uid=103 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/timedate1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.103" pid=2836 label="snap.thunderbird.thunderbird" peer_pid=3708 peer_label="unconfined"
exe="/usr/bin/dbus-daemon" sauid=103 hostname=? addr=? terminal=?'
[Sep17 13:18] audit: type=1107 audit(1726543127.777:263): pid=1538 uid=103 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/timedate1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.112" pid=2836 label="snap.thunderbird.thunderbird" peer_pid=4433 peer_label="unconfined"
exe="/usr/bin/dbus-daemon" sauid=103 hostname=? addr=? Terminal=?'
These messages do not appear after a reboot when the emails are correctly accessed.
Is this a timing issue with network connection of some sort after a long period shut down or is there some other explanation?
Is it that Thunderbird is called before the network connection to the server is established? I have established that it is not the server causing the problem as other users with Kubuntu 22.04 can connect correctly.
Comment