Ошибку удалось воспроизвести на актуальной версии thunderbird в Sisyphus: 147.0.1-alt1

По следующим шагам:
1) Развернуть samba-домен, подключить двух клиентов: P10, с версией thunderbird 141.0-alt0 (можно использовать снапшот репозитория за второе октября 2025) и обновлённую до Sisyphus систему (проверено на Workstation 11 и Workstation K 11 x86_64)
2) Создать профиль в общей директории Samba
$ thunderburd -ProfileManager 
Выбрать Create Profile -> пустая директория в пространстве Samba
Закрыть Thunderbird
3) Запустить thunderbird на системе обновлённой до Sisyphus с указанием пути профиля
$ thunderbird -profile <путь к профилю на СХД>

Результат: приложение падает - "Thunderbird had a problem and crashed"
В логе указана причина:
MozCrashReason: called `Result::unwrap()` on an `Err` value: UnexpectedLoginsApiError { reason: "Error executing SQL: database is locked" }

Выполнение команды

find <путь профиля на СХД> -name "*lock" -delete 

не помогает

Спасибо за репорт. Воспроизвёл, разобрался.

Корневая причина не в Thunderbird и не в новом Rust-хранителе паролей
как таковом. Проблема в связке SQLite + CIFS-mount с дефолтными
опциями cifs-utils (cache=strict, brl on).

NSS softoken хранит ключи и сертификаты в SQLite-файлах key4.db
и cert9.db в каталоге профиля. SQLite координирует одновременный
доступ через POSIX byte-range locks (fcntl F_SETLK). На CIFS с
cache=strict + brl эти локи через клиент-серверный SMB-протокол
возвращаются клиенту как непрерывный конфликт, который ничем не
разрешается. NSS делает до 30 ретраев (sdb.c::SDB_MAX_BUSY_RETRIES)
с 1-секундным busy_timeout - не помогает, потому что лок не
"временно занят", а застрял в нерешаемом состоянии.
NSS не может создать key4.db -> JSON-хранилище паролей в
Thunderbird не может зашифровать пароль (оно использует NSS как
шифратор) -> новый IMAP-аккаунт прописывается в prefs.js, но
пароля для него нигде нет -> в боковой панели аккаунт не
появляется, при попытке добавить его заново мастер ругается
"уже существует". В TB 145+ это проявляется заметнее, потому
что добавился второй слой - Rust login storage (logins.db),
который тоже SQLite и тоже падает на инициализации схемы.

В Mozilla эта проблема существует давно. Bug 1456888 (NSS 3.38,
2018) добавил в lib/softoken/sdb.c::sdb_init() детектирование
сетевой ФС через statfs() и cache-mode (БД физически живёт в
/tmp, синхронизация на шару при коммитах). Этот механизм
теоретически решал бы проблему, но в нынешнем коде он
активируется уже после первых BEGIN/CREATE TABLE, которые на
новом профиле как раз падают на лок. То есть на свежесозданном
профиле на CIFS защита из 1456888 простаивает.
Это отдельный upstream-баг.

Workaround:
mount -t cifs //server/share /mount/path \
-o cache=none,nobrl,<остальные ваши опции>

или, если работает через autofs, добавить cache=none,nobrl:
profiles -fstype=cifs,cache=none,nobrl,...,guest \
://server/share

Важно: nobrl отключает byte-range locking на всей этой шаре.
Безопасно для одиночного клиента (один Thunderbird на одной
машине). Опасно если предполагается одновременный доступ к
одному профилю с разных машин - SQLite не сможет защититься
от конкурентной записи, БД может побиться.
cache=none снижает производительность IO заметно, но работает.

Реальный фикс - на стороне NSS.
Upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=2042923

так может быть это проблема SAMBA а не nss ?
почему блокировки не отрабатывают нормально ?

(Ответ для Anton Farygin на комментарий #3)
> так может быть это проблема SAMBA а не nss ?
> почему блокировки не отрабатывают нормально ?

Нет, у SAMBA это скорее архитектурное ограничение протокола
и это проблема далеко не только у SMB:

https://www.sqlite.org/faq.html#q5 -
"SQLite uses reader/writer locks to control access to the database.
(Under Win95/98/ME which lacks support for reader/writer locks, a
probabilistic simulation is used instead.) But use caution: this
locking mechanism might not work correctly if the database file is
kept on an NFS filesystem. This is because fcntl() file locking is
broken on many NFS implementations. You should avoid putting SQLite
database files on NFS if multiple processes might try to access the
file at the same time. On Windows, Microsoft's documentation says that
locking may not work under FAT filesystems if you are not running the
Share.exe daemon. People who have a lot of experience with Windows tell
me that file locking of network files is very buggy and is not dependable.
If what they say is true, sharing an SQLite database between
two or more Windows machines might cause unexpected problems."

Mozilla в NSS 8 лет назад починила частный случай - производительность на NFS
с существующей БД. Краевой случай, первое создание БД на сетевой FS,
остался необработанным, потому что был редкий и никто его конкретно не репортил.
TB 145+ с Rust login storage этот краевой случай поднял до массового.
Переход со старого формата с json паролями на rust хранилище создаёт SQLite БД.

Когда у Mozilla дойдут руки и пофиксят порядок в sdb_init() -
проблема уйдёт у всех. Параллельно подумаю можно ли портировать
тот же ordering-fix вниз в наш nss как downstream-патч, не дожидаясь
upstream. Если получится - это будет реальный fix без необходимости
менять mount-опции.