При обновлении Alt Lunux обновляется Thunderbird со 141 на 145 версию. После этого не запускается мой профиль, который находится на Samba-ресурсе (СХД). Попробовал создать новый, пустой профиль на Samba-ресурсе, создаётся, не запускается. Новый, пустой профиль на локальном диске работает нормально. В journalctl ничего не вижу. Samba-ресурс доступен по записи моему пользователю, никаких проблем никогда не было, подключается по AutoFS. Пришлось вернуть почту из Snapshots на СХД, систему из TimeShift, уже более месяца стоит не обновлённая.
Ошибку удалось воспроизвести на актуальной версии 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-опции.
