Huh, I forgot to write that I even copied the mentioned local profile into my .thunderbird environment without avail, and into my home folder with same results. And I didn't mention that I found the same questions even here: https://support.mozilla.org/en-US/questions/1440794

However, the chosen solution seems to be rather frustration tha a real solution. I've tried it and also killing .parentlock and lock (the latter marked as wrong link in the file system) didn't work.

I fact, I have my mail archives stored in my local folder. It's a pain in the back always being forced to change to windows before mailing or storing anything outside IMAP folders. Actually, it's the first time I'm really happy still having Windows as a working backing system.

Mint is part of the problem. It uses ubuntu as a base and they now use sandboxed snap packaged instead of the older package manager format. ARCH I think.https://ubuntu.com/core/docs/security-and-sandboxing

The already running can be caused by the presence of a parent.lock file in the profile. With Thunderbird closed just delete the file.

Hi Matt,

Thanks for your proposal, but deleting "parent.lock" doesn't work. That's what I've found already in some fora. Before I've deleted even more, e.g. "lock" (a link, marked "faulty" in Linux) and ".parentlock" (0 byte).

Linux Mint 22 doesn't use Snap per default (I think it's installable - I'm not sure). Even more, they have introduced a purely Debian based edition - because of Canonical's own development paths - like Snap. Nonetheless, even being an apt package it might be broken somehow as it seems that the Mint guys are quite involved in some parallel developments concerning their code basis. However, I'll try asking in the Mint environment as well.

Before the last major upgrade of TB I'd been able to access both profiles from Windows and Mint. Both are stored outside the normal Windows environment, on a different drive. Instead of further trying to get access from Linux side, I created a pretty new profile and was able to import almost everything but my local folder.

I'm neither a dev, nor a Linux nerd. Rather a power user and I'm teaching on a voluntary base how to use TB and other useful FOS applications. As far as I can see the local content wasn't touched by the upgrade and is still in the original text format as it was before. It still works fine under Windows. I've even tried to copy it into the ".thunderbird"-folder in Mint, but it doesn't change anything. Linking the path even to this internal location still shows nothing in TB (as before) and the import fails as well.

I have exactly the same issue under two installations of Fedora 40. But I use Cinnamon so it might be the common factor (I have only RPMs on both systems, no flatpak or the same). Interestingly enough, the following works as expected:

   xdg-email myname@example.com
   thunderbird mailto:myname@example.com
   gio open mailto:myname@example.com

It gets even weirder: while clicking on a mail link in firefox, I see that it ultimately calls

   /usr/lib64/thunderbird/thunderbird mailto:myname@example.com

If I call the same from the command line, it works and doesn't get stuck.

One more piece of information: clicking on a mailto link in LibreOffice, or sending a file via email, works as it should, so it might have something to do with the way Firefox tries to send e-mails via Thunderbird. This said, I created a small script to know how it's called on mails, and it's simply called with `mailto:myname@example.com` as parameter, nothing else.

I think, I found a workaround and posted it there: https://bugzilla.mozilla.org/show_bug.cgi?id=630548

tl;dr: the MOZ* environment variables set by Firefox while calling Thunderbird do cause the issue.

Hi Eric, obviously several people do have the same message. At a first glance I didn't see any Win/Linux dual use of the same profile. I read somewhere that this kind of profile sharing never had been intended, even if it worked before without any issue. I think as well that it is a real bug. I wasn't able testing the way as you did as TB was not responding without any active local profile. I managed before the connection via the profile Manager and manually connecting the existing profile on a NTFS drive, making it, when working as expected as before, the default starting one. When choosing this profile now, I'm still getting the error message. EDIT: It stuck before I'm asked for my main password.

Well, now I doubled all local IMAP data (several different mail accounts), by having now an own profile in both worlds. Nonetheless, somehow I saw the miracle that the local profile, my mail-archive, is now accessible again from both sides and the calendar is synchronized via my NAS anyway.

However, thanks for sharing your ideas.