2036592 - Cannot authenticate while mail profile is on network share (with SELinux)

Status: NEW

(MailNews Core :: Backend, defect)

Description

[Stu G [:stu]]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36

Steps to reproduce:

Store Thunderbird mail profile on a remote NAS file share.
Mount the CIFS file share using systemd under Fedora Linux.
Start Thunderbird, access profiles and attempt to authenticate to remote mail servers.

Actual results:

After the upgrade to 146.0, starting Thunderbird with the remote profile caused a segmentation fault. See stack trace here https://bugzilla.redhat.com/show_bug.cgi?id=2430324
At Version 148.0 the seg fault stopped happening and allowed access to the remote profile. But account authentication to various IMAP mail servers failed.
The problem still exists at 149.0
Moving the profile onto the local machine allows everything to work, ever since the problem started with 146.

Expected results:

Mail authentication functions correctly with mail profile on remote file share.

Comment 1

[Magnus Melin [:mkmelin]]

IIRC during that time window the format of logins were converted to a newer format. If there were issues with the profile in the meantime perhaps the migration failed.

Do the creds work after you re-enter them?
You could try setting mail.ui-rdf.version to something small, to re-run migrations at startup. (Take backup before, to be sure.)

Comment 2

[Stu G [:stu]]

Existing Profile on NAS
Changing mail.ui.rdf.version doesn't solve this. It gets reset back to value 57 and changes the UI format.

Removing profile passwords causes Thunderbird to get stuck trying to connect to various IMAP servers. Closing Thunderbird at that point doesn't stop it's process right away, eventually resulting in a crash. See attached reports.

Removing all accounts from the profile allow Thunderbird to cleanly close. Local folders on the profile still work.

Recreating new IMAP email accounts recognises the server configurations in Mozilla ISPDB (for Fastmail and Gmail), but stalls at "Waiting for authorization in login popup". Here it is waiting for the OAuth 2 popup used by Fastmail and Gmail.
Attempting manual configuration at this point fails as it states the server configuration already exists.

New Profile on NAS
Creating a new profile on the remote NAS fails at setup of a new account using the auto configure options. It gets stuck on checking password.

Using manual setup with a Fastmail account it accepts the password, then gets stuck on "Account created. Discovering address books and calendars". If I skip this, it asks to enter the email account password and displays "Error Creating Account - Incoming server already exists".

Creating a Gmail account manually gets stuck on an authentication error when entering the password.

Creating email accounts for providers that don't use OAuth 2 seem to be able to be created, but don't appear in the GUI after creation. Shutting down after creating these sometimes causes a seg fault core dump.

New local profile
Creating a new profile on the local machine performs flawlessly. New accounts can be created as expected of all types.

Other observations
This appears to be a network related regression introduced at 146 but partially ameliorated at the 148. Seg faults persist in various states, but no longer on startup.

The fault is correlated to storing the profile on a network share and is easily reproducible. I have it also occurring on another machine with a separate mail profile for different user.

Comment 3

[Stu G [:stu]]

Attachment: Stack trace from crash after shutdown

Comment 4

[Stu G [:stu]]

Attachment: Stack trace from crash after shutdown

Comment 5

[Magnus Melin [:mkmelin]]

Vlad, can you check this?

Comment 6

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

Hello,

I attempted to reproduce this issue using both Fedora Linux and Ubuntu, as well as a Windows machine on the same network with a shared folder mounted from the Fedora/Ubuntu system.

Testing was performed on the affected build from when the issue was submitted, 2026-05-05 / 20260505090034, as well as on the latest Daily build, 20260602103050. However, I was unable to reproduce the reported behaviour in either case.

Comment 7

[Magnus Melin [:mkmelin]]

Stu G: can you try v151 (and or latest v152 beta)?

Comment 8

[Magnus Melin [:mkmelin]]

If you're using AppArmor, xref bug 2012946

Comment 9

[Stu G [:stu]]

Thanks for following up.
I tried installing v151. It doesn't work with a remote profile, all the same issues as before. Fails to authenticate and crashes on exit.
I'm running Fedora Linux with SELinux, not AppArmor.
The NAS is an older Synology Diskstation. I set the minimum SMB protocol to SMB2 and the maximum SMB protocol is SMB3. I also cleared the SMB cache, but it made no difference.

Comment 10

[Magnus Melin [:mkmelin]]

Apart from other configuration problems, SELinux seems like a probably cause of the issues. Please check your settings for that.

Comment 11

[Stu G [:stu]]

Thanks, it doesn't appear to be caused by SELinux.
When I set SELinux to permissive mode the problem persists with ver 149.

This is the message at the command line after running and closing Thunderbird:

stu@kappa:~$ thunderbird
RunWatchdog: Mainthread nested event loops during hang: 
 --- nsThread::WaitForAllAsynchronousShutdowns
Segmentation fault         (core dumped) thunderbird

Nothing indicating a Thunderbird authentication issue shows up in the log at /var/log/messages.
It does confirm Thunderbird is successfully mounting the remote NAS via systemd.
The next relevant message is the crash report on failing to shutdown.

Jun  9 15:50:45 kappa audit[9161]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=7 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=9161 comm="S
hutdow~minator" exe="/usr/lib64/thunderbird/thunderbird" sig=11 res=1
Jun  9 15:50:45 kappa systemd-coredump[9876]: Process 9161 (thunderbird) of user 1000 terminated abnormally with signal 11/SEGV, processing...

Comment 12

[Wayne Mery (:wsmwk)]

Surely oauth would be not be affected by profile being on a NAS?

You're not using this profile with multiple computers?

Comment 13

[Stu G [:stu]]

Yes it's strangely linked to any profile being on the NAS. Local profiles work.
I have the same fault on two different machines with different profiles. Only one profile is only being used on each computer.
It's not a profile corruption issue. New profiles on the network are also affected.
I've used these profiles remotely on NAS for years before this issue cropped up at 146.

Comment 14

[Magnus Melin [:mkmelin]]

Can you try v153?

Comment 15

[Stu G [:stu]]

Tested 153. Same issues as before sorry.
Will not connect to servers. Segmentation fault on exit.
On downgrading back to 140 it works perfectly.

Comment 16

[Max Emig [:maxe]]

The bug is real and cursed regressed by storing credentials AES-encrypted in bug 1985684.