Open Bug 1612414 Opened 5 years ago Updated 2 months ago

after update to TB 68.4.2 from 60.9.1 on mac OS 10.15.2, profiles located on nas will not open (smb mounted profile)

Categories

(MailNews Core :: Networking, defect, P2)

Product:
MailNews Core
Component:
Networking
Platform:
x86_64
macOS
Type:
defect

Tracking

(thunderbird_esr68 wontfix, thunderbird_esr78+ wontfix, thunderbird_esr91 affected)

Tracking Flags:
Tracking Status
thunderbird_esr68 --- wontfix
thunderbird_esr78 + wontfix
thunderbird_esr91 --- affected

People

(Reporter: mike.derby, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(16 files, 1 obsolete file)

MAC profile.ini.rtf
1.31 KB, application/msword
Details
TB78.2.0.jpg
109.10 KB, image/jpeg
Details
The Console messages, filtered for Thunderbird as rtf
21.86 KB, text/rtf
Details
The Console messages, filtered for Errors and problems as rtf
71.55 KB, text/rtf
Details
The Terminal messages as rtf (just in case...)
13.59 KB, text/rtf
Details
Bildschirmfoto 2020-09-06 um 21.48.03.png
108.16 KB, image/png
Details
Preferences Setting showing highlighted choice without text
27.98 KB, image/png
Details
Second image to accompany comment 58
28.60 KB, image/png
Details
Third image to accompany comment 58
61.75 KB, image/png
Details
60.9.1 on MAC.png
922.22 KB, image/png
Details
60.9.1on NAS.png
154.04 KB, image/png
Details
78.5.1 on MAC.png
277.48 KB, image/png
Details
78.5.1 on NAS.png
90.58 KB, image/png
Details
security.png
39.75 KB, image/png
Details
Mac Permissions - not changed, not working.png
71.93 KB, image/png
Details
Files and Folders permission
335.79 KB, image/png
Details
Attached file MAC profile.ini.rtf —

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36

Steps to reproduce:

TB profile on NAS was accessed by TB 60.9.1 on Mac (OS 10.15.2) and TB 68.4.2 on PC (WIN 10 18363.592). After Mac TB update to 68.4.2, TB on Mac opened blank page with totally non-responsive menu commands.

  1. Created new profile on local Mac HD and it opened, but was obviously empty.
  2. Copied new profile to NAS, changed pointer in profile.ini, opened same profile (but now on NAS) and this time obtained blank page with non-responsive menu.
  3. Copied profile back to Mac HD, and empty profile opened normally.
  4. Deleted < global-messages-db.sqlite > from both old and new profiles on NAS without effect (files recreated, but still blank page with non-responsive menus)
  5. Used Time Machine to return to previous version of TB (60.9.1) and normal function returned (TB opened NAS profile without problem)
  6. Reinstalled 68.4.2 and problems reappeared as described above.

Actual results:

Previous profile on nas opens OK with TB on PC, but with blank, non-responsive page after TB update on Mac, although worked fine before upgrade. New profile created on NAS with profile manager shows same response. Profile created on local hard drive opens with responsive menu commands, but shows blank page and non-responsive menu if moved to NAS. PC unaffected and can see new NAS profile created if PC profile.ini changed to include it.

Expected results:

Update on Mac to 68.4.2 from 60.9.1 should have transitioned without any issues as all previous updates have always done in past, especially since PC was already running TB 68.4.2 and accessing NAS profile without issues. Since TB 68.4.2 on Mac recognizes local profiles, but not old or new profiles on NAS, issue seems to be in implementation of TB 68.4.2 on Mac 10.15.2 .

Summary: after update to TB 68.4.2 from 60.9.1 on mac OS 10.15.2, previous profiles on nas not opened → after update to TB 68.4.2 from 60.9.1 on mac OS 10.15.2, previous profiles on nas will not open
Summary: after update to TB 68.4.2 from 60.9.1 on mac OS 10.15.2, previous profiles on nas will not open → after update to TB 68.4.2 from 60.9.1 on mac OS 10.15.2, profiles located on nas will not open

How is the NAS mounted? Is it using NTLM authentication?

The profile on the NAS (a QNAP TS-253A running standard software) can be accessed without any issues from a PC running Windows 10 (18363.592) using a PC specific profile.ini (to provide a PC-compliant pathway to the NAS profile). The NAS drive is mapped as "T:" and connected at startup.

The MAC mounts the NAS "Thunderbird" directory as a user login item using SMB. The way in which it is mounted has not changed from when it was working under 60.9.1.

Here are the platform-specific versions of profile.ini (and remember, these both work fine if the mac is running 60.9.1 and the PC 68.4.2):

Mac profile.ini

[General]
StartWithLastProfile=1

[Profile0]
Name=default
IsRelative=0
Path=/Volumes/Thunderbird/Profiles/y0b10hgg.default
Default=1

PC profile.ini

[General]
StartWithLastProfile=1

[Profile0]
Name=default
IsRelative=0
Path=T:\Profiles\y0b10hgg.default
Default=1

I wonder if changing either network.auth.force-generic-ntlm-v1 to true or network.auth.force-generic-ntlm true makes a difference?

Summary: after update to TB 68.4.2 from 60.9.1 on mac OS 10.15.2, profiles located on nas will not open → after update to TB 68.4.2 from 60.9.1 on mac OS 10.15.2, profiles located on nas will not open (smb mounted profile)
Whiteboard: DUPEME

After installing Thunderbird 68.4.2, it opens a "non-responsive" instance without any associated accounts. While some commands actually do produce a response (such as "Thunderbird > About Thunderbird" and "Thunderbird > Services > Service Preferences"), and one can set up new accounts in the new local profile using "File > New > Get a New Mail Account"), "Thunderbird > Preferences" does NOT open the preferences page, and (perhaps as one might expect) "Help > Troubleshooting Information" does NOT open the Troubleshooting page.

So... A little help, please. How can one access the Preferences Page and (more specifically) the Config Editor directly to make the suggested changes?

In that case, maybe use a user.js file - see http://kb.mozillazine.org/User.js_file
Add these:

user_pref("network.auth.force-generic-ntlm-v1", true);
user_pref("network.auth.force-generic-ntlm", true);

As I started to insert a user.js file, it dawned on me that both instances of Tbird share the same profile located on the NAS. I guess I was under the assumption that there must be a local mac-specific file (or setting) that prevented 68.4.2 from functioning on the mac and that I would need to deal with it from the mac. Given the common profile on the NAS, however, I can access the Profile Editor from the PC to make profile changes. [by the way, both of the suggested settings are currently false]

Before I waste a lot of time dealing with installing/uninstalling and Time Machine recoveries, do you have any idea how the profile changes will impact the PC instance of Tbird (which is working just fine)?

I have made one change without any result. I discovered that, even though I have Win 10 64-bit, the 32-bit version of 68.4.2 had been automatically installed at update. So the 64-bit Mac 60.9.1 and the 32-bit PC 68.4.2 both accessed the same NAS profile without issues. Found and installed the Win 10 64-bit version of 68.4.2 and it sees the Profile properly, BUT version 68.4.2 on the Mac is still a No-Go.

So lessons learned: both automatic update process (as well as Big Green Download Button at https://www.thunderbird.net/en-US/) apparently do not check Win 10 32- vs 64-bit versions and default to the 32-bit version.

By the way, I came across a post showing that this problem with 68.4.2 on the Mac has been described before -- no solution there either. They just did what I did: reverted to the 64-bit 60.8/9 for macOS. (https://support.mozilla.org/en-US/questions/1271805)

Those pref changes would probably not do much change for the windows version. But you can drop them once you tested.

Was concerned that I would lose ability to get back into Preferences Editor from the PC version. I guess could always just use a user.js file if problems.

Made the changes. No impact on version 68.4.2 on the mac.

More suggestions?

Depends. If you're willing to track down the regression range that would be really useful for getting to the bottom of this problem. You'd check builds from http://ftp.mozilla.org/pub/thunderbird/nightly/2018/ and http://ftp.mozilla.org/pub/thunderbird/nightly/2019/
You'd start from two dates, say 2018-08 and 2019-04, then take a build from ~half the time until you find when it broke. For starting up use --allow-downgrade
And do make a backup of the profile first.

Looks like it may take awhile, but will get started this evening. I'm assuming that I should focus on the "-comm-central/" directories for US English versions?

Correct!

Latest...

Downloaded DMG files for versions 61.0a1 up through 66.01a, opened the DMG file, and then started the Thunderbird app from within the "mounted" DMG file. All opened OK and saw profile. However, when I opened the 67.0a1 (2019-02-28) (64-bit), it showed the same behavior as 68.4.2.

I then opened the daily from 2019-02-01 and it showed the same behavior (I wasn't sure exactly what would change on each daily since the DMG files all had the same file name, but were saved as a daily version).

So there is a change in the app contained within the DMG files from version 66.0a1 (2019-01-28) (64-bit) to version 67.0a1 (2019-02-01) (64-bit).

Hope this helps.

Good Luck!

I doubt the comm-central changes could have caused it. Bug 1474285 perhaps, or then some compile change (maybe the one related to sqlite).

Do you see a similar problem for Firefox?

I don't have a common profile for Firefox since it syncs its operating characteristics over the web. In contrast, with Thunderbird I'm trying to keep a single, local repository of downloaded and sent emails (so I need one common profile where they are stored). The only common location I need for Firefox is where it stores downloaded files, and that can be specified independently in each local PC and Mac profile.

To be honest, while Firefox used to be my preferred browser, sometime over the past year Firefox stopped opening websites and otherwise began acting contrary. I understood changes had been introduced to increase security, but since I couldn't find an easy way to provide exceptions, I switched browsers to Chrome. It has it's own problems, but I find it easier to identify and introduce exceptions for the way I use it and now use Firefox as a backup when Chrome refuses to cooperate. Current Mac version of Firefox is 72.0.2 (64-bit) [up to date].

So, I copied a duplicate of the Firefox profile onto the NAS, made it default, and then restarted Firefox. After a while, it popped up a window saying it had crashed, but when I clicked the open Firefox button, it opened the window to choose profiles. Choosing the new NAS profile, it started with my usual 3 tabs, 2 of which had the appropriate tab name and website address (while the other was labeled "New Tab"). All were blank. The refresh button was grayed out for all tabs, but, for the named tabs with addresses, if I selected the website address in its window and hit "Enter", the correct website opened. Not sure what this signifies.

Despite this, all menu commands worked (unlike Thunderbird) and, especially important, the "Firefox > Preferences" and "Help > Troubleshooting Information" menus worked (as did menu items on the Hamburger icon), and my usual Add-ons were present. This suggests to me that the existing Profile was being seen OK, although I'm not sure why the websites did not open.

Hope this information is helpful. If you'd like me to look closer at the Firefox NAS profile, let me know.

UPDATE

After comparing directories, discovered that the Firefox profile didn't get copied to the NAS correctly (apparently problems with Path Finder file manager on Mac). Recopied using Mac Finder and Firefox works perfectly with profile stored on NAS.

Thus the Thunderbird problem is some change that occurred between the latest dated comm-central 66.0a1 version and the earliest 67.0a1.

Alex, is this something you could track down?

Flags: needinfo?(alessandro)

I currently don't have a NAS to perfectly recreate your setup, but I could try simulating a similar situation.
These are the things I'll try to do:

  • Move the profile to an external HD mounted on login.
  • Move the profile to another computer and mount the shared folder on login.

Did you already try doing something similar?

Flags: needinfo?(alessandro)
Assignee: nobody → alessandro
Keywords: regression
OS: Unspecified → macOS
Priority: -- → P2
Hardware: Unspecified → x86_64

I believe we've had a few similar reports. Mac + profile mounted elsewhere using samba or some other form (I think ntlm auth was a suspect). Bug 1611816 may also be a dupe.

You would better know the previously reported bugs. In comment #6 above, I found another report about this on the support forum (https://support.mozilla.org/en-US/questions/1271805)

I thought I had commented on potential test setups, but I guess not. A directly connected HD is unlikely to reproduce the problem - anything on a USB or PCI bus would probably be seen as local.

Connecting to a HD on another computer located on a ethernet LAN is likely to work (if you have to mount it from "Network" using Finder, should be equivalent to mounting the NAS HD).

New update arrived with dire warnings about security. Installed it (68.6.0). Still broken! Used Time Machine to recover 60.9.1.

Any progress on discovering the issue? If security problems really are serious, will need to start looking for a Thunderbird replacement.

Are we deciding that this is a bug that cannot be resolved? I need to make a decision soon about whether to transfer to another client from Thunderbird if this will remain an unsolved issue.

We'd like to fix it but I don't think we yet reproduced.
Is it still an issue with Thunderbird 78 beta? https://www.thunderbird.net/en-US/#channel

I'm trying to get my boat into the water, but will have some time over the next couple of weeks to try with both version 78 and by referencing files stored remotely on my PC. If the problem is present using files on the remote PC drive, then that should provide a system that you guys can look at in the absence of a NAS.

There is also bug 1609050

See Also: → 1609050, 1611816

Mike, how does it look with version 78.1.0 - better, worse?

Flags: needinfo?(mike.derby)

I just tried 79.0b3 and it's still broken. Returned to 68.11.0 by simply replacing the 79.0b3 program in the Applications folder with the 68.11.0 program from Time Machine and it returned functionality. My PC is on the latest Release version and uses the same profile on the NAS without problems, so (to repeat myself), it looks like it is a problem within the MAC program (app) itself, a problem which is not present in the PC version.

Flags: needinfo?(mike.derby)

After testing extensively on defect #1578539, I now realize that my problem is actually this one, because creating a new profile with TB 78 in an empty folder on my NAS fails exactly as described above, while it still works fine with TB60.
Using macOS 10.15.6 (=the latest) and TB 78.1.1 with a Synology NAS.
I agree with everything above, including the accessibility from Windows 10 (using Parallels Desktop on my Mac), but this is a nightmare speed-wise, so no valid alternative.
Although this does not seem one of the many access restrictions of Catalina, I still tried giving TB full disk access in the Privacy settings, but no change in behaviour. And again, TB60 still works on this machine...
If there is anything I can help with, please let me know; I'd much prefer to keep my data on the NAS.

One more thing: it makes no difference if the NAS is mounted using smb or afp...

for the records: same issue here, with some remarks on terminal messages in the post of April 28:
http://forums.mozillazine.org/viewtopic.php?f=31&t=3058340

When using version 78, please use 78.2.0 which will be out next week, but you can use the candidate from https://archive.mozilla.org/pub/thunderbird/candidates/78.2.0-candidates/build1/

Also, a profile of the performance will be helpful. Please see https://github.com/thunderbird-conversations/thunderbird-conversations/wiki/Profiling-Conversation's-Performance

Attached image TB78.2.0.jpg —

I can confirm that 78.2.0 behaves the same.
Performance profile is difficult because there's nothing to record. As stated above, most menu points do not show any effect, not even the Hamburger menu can be opened. Yes, I can open the developer tools via the top menu, but what to record? Adding an e-mail account - nothing. Opening preferences - nothing. There is no way to connect to an account or profile, and therefore to show any e-mail.

To make it easier, I summarize the situation as I see it:

Definitions:

  • MacHD: the internal Mac SSD with MacOS and the Thunderbird app (MacOS changed from Mojave 10.14 to Catalina 10.15 over time)
  • NAS: Synology NAS running the latest DSM 6.2.3-25426 Update 2 (no noticeable difference between AFP or SMB network connection)
  • blank TB screen: top menus can be selected but most don’t work (i.e. preferences can not be opened, e-mail account can not be connected), Hamburger menu does not work at all. When started with Profile Manager, a new profile can be created but TB stays non-functional.

1.: TB profile on NAS:
TB 60.9.1 works as expected.
Later versions (incl. 78.2.0 RC) show blank TB screen.

2.: TB profile moved to MacHD:
TB 60.9.1 works as expected.
TB 78.2.0 RC works as expected.

3.: TB profile moved back to NAS:
TB 60.9.1 works as expected.
TB 78.2.0 RC shows blank TB screen.

My non-professional conclusions:

  • Both TB versions 60.x and 78.x do not change the profile in any way which make it unusable for the other version (which is great!).
  • *** The TB version directly following 60.x broke the NAS access from MacOS ***
    (I ran into this issue at the first update from 60.x but mistakenly thought it’s Bug 1578539).
  • It seems that Bugs 1612414 and 1609050 are actually the same Bug.

I wonder if running a debug build could show some usefuls errors (they do output a lot of non-useful ones as well).
Here's a 78 debug build: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/QDUnx8R3SviT2SN6uID9vw/runs/0/artifacts/public/build/target.dmg - back up the profile. Then start with the -P switch to choose the right profile

(In reply to Magnus Melin [:mkmelin] from comment #36)

I wonder if running a debug build could show some usefuls errors (they do output a lot of non-useful ones as well).
Here's a 78 debug build: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/QDUnx8R3SviT2SN6uID9vw/runs/0/artifacts/public/build/target.dmg - back up the profile. Then start with the -P switch to choose the right profile

I tried as you suggested but no difference in behaviour, and no errors popping up.
If you're looking for some log files or such, please tell me exactly which ones I should upload here; at least in my profile folder I did not notice anything unusual.

Seems like this would be the right component.

Component: Untriaged → Networking
Product: Thunderbird → MailNews Core

When you start the debug build it from the command line you you should see loads of output (in the native console)

(In reply to Magnus Melin [:mkmelin] from comment #39)

When you start the debug build it from the command line you you should see loads of output (in the native console)

Flags: needinfo?(mike.derby)
Flags: needinfo?(apdus)
See Also: → 1578539
Flags: needinfo?(apdus)

(In reply to Magnus Melin [:mkmelin] from comment #44)

For some reason you end up at https://searchfox.org/mozilla-central/rev/ac142717cc067d875e83e4b1316f004f6e063a46/toolkit/components/xulstore/old/XULStore.jsm#66, but I don't see any clues to why.

This is the first time I hear of searchfox, so it's definitely nothing I configured deliberately.
I attach a screenshot of the code line where I end up at when clicking on the link above.
(Not that I understand anything of it; please don't forget, I'm a user, not a programmer, but again I appreciate your help a lot!)

I was just linking to the online code reference (searchfox) of which code path we ended up with.

Just a quick heads up on this bug to let you know that I purchased a NAS I should receive next week.
I will set it up to emulate the configuration of the reporter and test it with macOS.
We will get to the bottom of this.

All right, I got the NAS and everything is up an running.
I'm using a Synology DS920+ with 4 HDD in Raid 5, 28TB of space formatted in ext4.
Now I'd like to emulate your setup as much as possible.

  • Is your NAS mounted at startup?
  • Direct Ethernet connection to the router, or via WiFi?
  • Is your profile in a encrypted folder?
  • Is your profile in a folder protected via Master Password?
  • Is your folder accessible to your NAS admin account or do you have a dedicated user for it?
  • Any other unique configuration I should be aware of?
Flags: needinfo?(mike.derby)

• Is your NAS mounted at startup?
o NAS is a QNAP TS-253A configured as RAID 1; Thunderbird volume is mounted at startup on both Windows 10 PC and Mac mini
• Direct Ethernet connection to the router, or via WiFi?
o Direct (wired) ethernet from both Mac and PC through Netgear C6300
• Is your profile in a encrypted folder?
o No
• Is your profile in a folder protected via Master Password?
o No – but I automatically log on to NAS volume with ID and password from both computers at startup
• Is your folder accessible to your NAS admin account or do you have a dedicated user for it?
o It is accessible to the admin account
• Any other unique configuration I should be aware of?
o I don’t think so. I kept the NAS setup as straight-forward as possible to avoid issues with using both the Mac and the PC

Let me know if you have any other questions. I'd like to participate, but it has been a long time since I programmed (Fortran and C++), so troubleshooting this is a bit beyond me now.

My setup is pretty similar to Mike’s above:

• Is your NAS mounted at startup?
NAS is a Synology DS215j configured as RAID 1; Thunderbird volume is mounted at startup on two Macs (but can also be started and accessed from another MacBook and iPads / iPhones using Synology’s DS file app; no Thunderbird in use here though)

• Direct Ethernet connection to the router, or via WiFi?
Direct (wired) ethernet from two Macs and wireless from other devices

• Is your profile in a encrypted folder?
No

• Is your profile in a folder protected via Master Password?
No – but I automatically log on to NAS volume with ID and password from both computers at startup

• Is your folder accessible to your NAS admin account or do you have a dedicated user for it?
It is accessible to the admin account

• Any other unique configuration I should be aware of?
I don’t think so. I also kept the NAS setup as straight-forward as possible

Many thanks again!

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Finally I'm able to confirm this bug after completing the setup.
Indeed, I can confirm that smb or afp doesn't change anything. I'm sticking with afp as it's faster in transferring files for me.

I'm using daily for testing and debugging, which comes with the same issue anyway.
Here's a bunch on interesting console errors when trying to launch it:

JavaScript error: resource:///modules/gloda/GlodaDatastore.jsm, line 1510: TypeError: 
can't access property "tableExists", this.asyncConnection is null

This error is repeated 11 times.

And then we get these other errors:

JavaScript error: , line 0: uncaught exception: migrate error: StoreError(LmdbError(Other(45)))
JavaScript error: chrome://messenger/content/messenger.xhtml, line 288: TypeError: 
can't access property "onLoad", gMailInit is undefined
JavaScript error: chrome://messenger/content/messenger.xhtml, line 1: TypeError: 
can't access property "onOverflow", QuickFilterBarMuxer is undefined
JavaScript error: chrome://messenger/content/mailWindow.js, line 624: TypeError: 
tabmail.getBrowserForSelectedTab is not a function
JavaScript error: chrome://messenger/content/mailWindow.js, line 624: TypeError: 
tabmail.getBrowserForSelectedTab is not a function
JavaScript error: resource:///modules/gloda/GlodaDatastore.jsm, line 1510: TypeError: 
can't access property "tableExists", this.asyncConnection is null
JavaScript error: chrome://calendar/content/calendar-tabs.js, line 376: TypeError: 
tabmail.registerTabType is not a function
JavaScript error: chrome://messenger/content/mailWindow.js, line 624: TypeError: 
tabmail.getBrowserForSelectedTab is not a function
JavaScript error: chrome://messenger/content/chat/chat-messenger.js, line 1555: TypeError: 
tabmail.registerTabType is not a function

Let's see if I can find a fix!

More info from the log:
"Unexpected error when trying to open the database: [Exception... \"Component returned failure code: 0x80630002 (NS_ERROR_STORAGE_IOERR) [mozIStorageService.openUnsharedDatabase]\" nsresult: \"0x80630002 (NS_ERROR_STORAGE_IOERR)\" location: \"JS frame :: resource:///modules/gloda/GlodaDatastore.jsm :: _init :: line 1113\" data: no]"

Failure happening in this method: https://searchfox.org/comm-central/rev/c0902daf234fbaf29442922790c6a080c6e56cc1/mailnews/db/gloda/modules/GlodaDatastore.jsm#1068

I'm not sure, but it might be related to the changes in the mozStorageService.cpp file that happened in that time frame you gave in comment 13.

These are some matches I found:
https://hg.mozilla.org/mozilla-central/diff/47e8e726d241221405bb859742caeb1bb6de1736/storage/mozStorageService.cpp
https://hg.mozilla.org/mozilla-central/diff/d7d0d7ad4c0bc5dad1031d2101dd2e46777f9f7c/storage/mozStorageService.cpp

Bug 1658345 comment 1 indicates potentially adjusting the rsize of the mount options could play into the picture. E.g.
vers=default,uid=0,noforceuid,gid=0,noforcegid,rsize=1048576,wsize=1048576

No luck for me unfortunately.
I can't seem to find a way to properly mount the volume and changing the mount options.

I tried to follow this guide with all 3 protocols (afp, smb, nfs) without any luck.
https://gist.github.com/L422Y/8697518

I'll keep trying.

The new version of MacOS (OS 11.0.1 = Big Sur) causes a bunch of problems with display formatting in 60.9.1 that will complicate problem solving. The account/folder area to the left of the Tbird window is now uniformly gray (no visible text). The items are still there because you can select them by clicking on where they are supposed to be. Also, the selected label in a menu choice disappears when selected but will reappear in a highlighted box if you click on the desktop to move focus off the menu window.

Best shown by a screen shot, but I don't know how to include one here. The Main window with the gray left panel that has no visible text appears easy to grasp, but the other needs a little more explanation. For example, in OS 11.0.1, in the Thunderbird Preferences / Display tab, if you select "Formatting", the items box gets a highlighted surround and turns white inside and there is no text visible. If you then click on the desktop to move focus, the item box loses its highlighted surround, the "Formatting" item background remains white, but the text now appears as usual.

I realize this is a new bug, but I can't tell if it is unique to 60.9.1 because the latest version of Tbird will not run on my Mac with the profile stored on the NAS. This essentially makes Tbird with the profile on a NAS unusable. I can use my PC for email for awhile, but if we can't find a solution for this soon, I am going to have to look elsewhere for a email client and figure out how to move a few years of emails.

Image to accompany comment 58

Image showing text for selected menu item appears if focus moved to desktop

This is a screenshot of the main Thunderbird window. Note the entire left panel is uniformly gray without text, but I have clicked on the spot where my Inbox should be located and it shows a gray selection for that item and the inbox contents do appear in the right panel as expected

(In reply to mike.derby from comment #58)

...
The Main window with the gray left panel that has no visible text appears easy to grasp, but the other needs a little more explanation.

not this bug report, but perhaps related to bug 1677272, or one of the other big sur bug reports

I thought the screen shots would be helpful, but if you meant more explanation from me, then...

The image in comment 59 shows the MacOS Thunderbird Preferences window opened and with focus (that is, the window is selected and active), the "Display" tab has been selected, and the First sub-tab ("Formatting") selected. The sub-tab selection box has a Blue highlighted surround, but the inside is white with no visible text.

If one then clicks on the Desktop, or on any other window on your Desktop to take focus off the Preferences window, you get the results in comment 60: The Thunderbird Preferences window loses focus: the Heading Bar across the top turns from Gray to White, the Formatting sub-tab loses its Blue highlight surround line (it turns back to a Gray surround line), and the title ("Formatting") appears as Black text on a White background.

This is NOT similar to Bug 1677272, but remember, these results are seen with version 60.9.1, NOT the latest version (if I could get a fix for Bug 1612414, then I would be using the latest version and possibly also be reporting the delay problems). I see no delays with version 60.9.1, and this issue seems to be with the definition of text colors under specific conditions, not with a delay in response.

(In reply to Magnus Melin [:mkmelin] from comment #56)

Bug 1658345 comment 1 indicates potentially adjusting the rsize of the mount options could play into the picture. E.g.
vers=default,uid=0,noforceuid,gid=0,noforcegid,rsize=1048576,wsize=1048576

mike did you test this?

Flags: needinfo?(mike.derby)

No, sorry, I haven't tried. First, I haven't coded in years and am basically just an end user now, but more importantly, I can't access any relevant menus.

In addition to the previously described issues, I have found many other windows that are "Blank" and show no text. These include the hamburger menu and submenus, and submenus accessed from the top Apple Thunderbird App menu bar. For many of these, "Escape" won't back out of the window and "Enter" sometimes works, but you have no clue what you are entering because you are clicking on a box that appears empty.

Flags: needinfo?(mike.derby)

I’m in no hurry to move to Big Sur, but if this is required to have the latest TB access profiles on a NAS; I’d do it. However, if new TB versions still can’t access profiles on a NAS, and TB 60.9.1 becomes less and less usable with Mac OS, we may have to change to something like eM Client. Kind of disappointing…
I mean, I know it sounds kind of obvious, but don’t you have access to the Apple developer network, to get some information on solving this issue? I know Apple likes to change things deep in OS and often without announcements, but usually the Apple developers are very helpful, once you found the right one to talk to (according to the driver programmers I used to work with…)? Also contacting Synology might help…

I don't have much faith in Apple to accomplish anything very fast... if they decide they even want to try.

Unrelated story to make a point:
I have a Mac mini with an external graphics card and somewhere around MacOS 10.14 or 10.15, it refused to display the screen. The graphics card turned on, but there never was any output to the monitor. I reported this to Apple, who escalated me up the chain and eventually had me take the computer into the local Apple store (with graphics card enclosure). They (of course) found no hardware issues since the update caused the problem and said don't use the external graphics card. After a couple weeks of online research and various troubleshooting, I discovered that if you shut off the graphics card, started the computer, and then restarted the graphics after 20-30 sec, all worked OK, until you shut down or restarted the computer. I reported this to Apple, who was sympathetic and said to wait for the next OS update. So I waited, using the 2-step startup procedure, but it was never fixed in OS 10. Now, FINALLY, it has been fixed in Big Sur, OS 11, so I am reluctant to go back to OS 10.

My point is that Apple frequently ignores end-user comments, if those end users are only a small fraction of all users, and even then it can take a VERY LONG TIME to obtain a resolution (usually without any feedback or notification about progress).

I really don't currently have the coding expertise to work on this NAS bug, all I can do is report the problem and try solutions. I know you guys are working on it, and I really don't want to have to move to another email client, but both the old and new versions of T-bird are unusable on my Mac at the moment. Presently, I'm using only my PC to access email, but that defeats the whole reason I moved to T-bird in the first place.

Pinging Ishikawa for some help on this issue.
Magnus told me that you identified some issues in the past that might be related to this.

Quick recap so you don't have to read 70 comments:

Any help would be immensely appreciated.

Flags: needinfo?(ishikawa)

(In reply to mike.derby from comment #69)

I don't have much faith in Apple to accomplish anything very fast... if they decide they even want to try.

Good call. But this is looking like the problem is not caused by Apple. Or, at least solvable on this end - potential solution developing in bug 1658345.

I really don't currently have the coding expertise to work on this NAS bug, all I can do is report the problem and try solutions.

The workaround suggested in comment 56 does not require coding - just changing mount parameters

Changing parameters appears to have no effect

(In reply to Alessandro Castellani (:aleca) from comment #70)

Pinging Ishikawa for some help on this issue.
Magnus told me that you identified some issues in the past that might be related to this.

Quick recap so you don't have to read 70 comments:

Any help would be immensely appreciated.

Hi, I am trying to digest the issue.
I am a bit puzzled that TB under linux and windows can access the profile on remote file system while TB under MacOS fails to do so.

Short READ occurs when a remote file server returns a smaller number of bytes requested by read request.
This may happen due to the remote system workload, the network route packet size limit, packet reassembly issues under heavy load of a router,
transient network errors, etc. This is fact of life.
When that happens, the requesting program needs to read the remaining bytes by re-reading the file stream again.
(cf. Short read is mentioned in NFS v3 protocol spec. https://tools.ietf.org/html/rfc1813
That is the well-defined behavior of an NFS v3 server. But I have known that a few CIFS/SMB servers do seem to cause short read to occur under heavy workload, etc.)
The short read issue is a fact of life in network programming. So the network code takes care of that routinely.
However, when the network access is hidden under a simple |read()| system call, people don't realize the issue exists.

The short read issue is hidden under the rug under Windows.
I have found out that Windows read system calls handles this short read issue WITHIN the OS
as far as CIFS/SMB file protocol is concerned. Clever to a point.
The applications are shielded from this Short READ issue if the remote file system is CIFS/SMB. (I have forgotten if Short READ of
NFS or other remote file system protocol are taken care of by Windows. Quite likely they are not.)

So that brings about the issue under Linux and MacOS, both posix-compliant OS.
POSIX does not say anything to prohibit Short READ for the file system read.
(Short read only began to surface when NFS was introduced.)
So we must fix M-C/C-C TB (and presumably FF) to handle short read that occurs via file system READ call.
I have produced a set of patches on top of some other local patches for C-C TB.
(That is I have noticed there ARE M-C issues as well, but I focused on fixing C-C issues first because
obviously the most frequent READ operations with TB occur in the reading of messages from remote server.
Firefox DOES handle short read via the network explicitly. However, if the read is from a file system, it does not care much.
Unfortunately, we have cases where our profiles are stored in remote file system now on top of largish mail archives.)
I tried to pave the way for M-C fix by introducing a helper function to deal with short READ, but that is when I found out
MacOS I/O SDK behaved slightly differently from linux/solaris implementation with regard to the error handling and the patch was backed out.
(It did not help that when the problem was noticed, my PC was fried and I could not repair it for about a month or so.
It was due to the external harddisk enclosure failure while I thought it was the motherboard issue and the fix did not proceed well.)
So short read issues of M-C portion with regard to (possibly remote) file system read is not handled, but like I said, explicit network read has been hardened.
It is only the read from file systems that are prone to the short read problems.

So word of caution, there are a few potential error causes, and mine only deals with
Short READ in C-C code. This time's error could be in M-C code.
But linux version works. That PUZZLES ME GREATLY. It COULD be MacOS specific.

Before diving into that C-C short read patch set, I need to keep tabs on the MacOS Big Sur environment

First thing first, can you verify that there is no SMB version incompatibility issue between MacOS Big Sur and the server side?
Lately many OS distributions decide to ditch SMB 1 due to security concerns.
But the default setting of not using SMB 1 has been known to cause issues.
The client side and server side need to agree on the SBM versions they use.
I am not familiar with Big Sur and not sure how to find the version used.
But here is a mention of SMB incompatibility issue with previous (?) version of MacOS, Catalina.
https://www.techarp.com/software/macos-catalina-nas-failure/
You may want to check it out.

Another interesting tidbid about SMB failure for BETA version of Big Sur is as follows.
https://developer.apple.com/forums/thread/659331
I suppose, though, this has been fixed with the final release, but given that the posts are two months old, the problem may still lurk in some early distributions.

So before doing serious debugging, can you make sure that other programs on MacOS Big Sur can see the files on the remote server, and copy them and write them on the remote file system without visible errors?
I don't have any I/O intensive program for suggestion.
Bonnie++ and fsx comes to my mind, though.
(They are listed in luster test page. https://wiki.lustre.org/Test_Descriptions )

Also,
(In reply to mike.derby from comment #72)

Changing parameters appears to have no effect
Comment 56 had this parameter.
.... rsize=1048576,wsize=1048576

So changing this rsize does not have any bearings on the error, correct?.

That said, I have submitted a tryserver run with full set of local patches to handle short read (plus some more that are in my local patch queue), I wonder if someone can see if that MacOS binary can start up by reading the profile on remote file system.

I have not realized that I did not create OSX debug build for quite some time. So tried to experiment a few times.
The binary from this tryserver ought to be testable for start up issue.
https://treeherder.mozilla.org/jobs?repo=try-comm-central&selectedTaskRun=L80Ig-WuRWW5sKklhhijFg.0&revision=8960707587b89abdec8ecd300a740979fc16902e

To: Wayne
Wayne, maybe you can show us where to look for the binary from the above job.

NOTE: the binary is only meant for testing this bugzilla.
Not for production use yet. (I see errors in the test and I have to figure them out.)

The success rate would be 50%. This somewhat pessimistic view is because

  • the CURRENT binary for Linux seems to work.
    (Windows binary does not suffer from short read. Windows read system call handles short read under the hood.)
    There does not seem to be any difference between the M-C/C-C low-level I/O wrappers of linux and MacOS.
    So there may be some problems of Big Sur and remote CIFS/SMB server, that are not handled by short read patches in C-C part alone.
  • OTOH, the behavior of CIFS/SMB server may be influenced by the behavior of client SMB daemon with regard to
    short read, i.e., returning of small chunks. It may be that MacOS Big Sur CIFS/SMB client implementation may be more prone to cause short read to occur.
    If this is the case, then the try-comm-central binary may work overcoming short read.
  • MacOS SDK + M-C/C-C low-level I/O wrappers behaved slightly differently from Linux/Solaris
    implementation regarding the handling of EOF or something if I recall correctly. So the new binary might shed some light on the problem even if the try-comm-central binary does not work. The debug version prints copious amount of log messages to the tty console where it started. That may give us a clue about what is causing the issue.

TIA

Flags: needinfo?(ishikawa) → needinfo?(wayne.mery)

After reading the thread I realized that some earlier versions do connect to NAS and work as expected.
Very strange.
It is possible that Apple SDK may have changed ever so slightly again in terms of error code handling (assuming that there are different versions of SDK linked to the latest version of TB and the older version of TB.)

Hmm...

So before doing serious debugging, can you make sure that other programs on MacOS Big Sur can see the files on the remote server, and copy them and write them on the remote file system without visible errors?

I did a very simple test where I copied 10GB from my HDD to the NAS, and back from the NAS to my HDD. It was a single 8k video and the process completed without issues.
I also copied a folder with 100 raw pictures, no errors encountered.
Let me know if there's a tool or a specific workflow you want me to use.

Users reported that up until TB 60, everything worked properly.
Magnus pointed to a possible regression range in Comment 13, I don't know if that could be helpful.

Thank you so much for looking into this.

I agree, it may be possible a real fix may be Mac specific. Might also be SDK related.

Short read patch (if it really does help) may not be a workaround for everyone.

(In reply to ISHIKAWA, Chiaki from comment #73)

...
That said, I have submitted a tryserver run with full set of local patches to handle short read (plus some more that are in my local patch queue), I wonder if someone can see if that MacOS binary can start up by reading the profile on remote file system.

I have not realized that I did not create OSX debug build for quite some time. So tried to experiment a few times.
The binary from this tryserver ought to be testable for start up issue.
https://treeherder.mozilla.org/jobs?repo=try-comm-central&selectedTaskRun=L80Ig-WuRWW5sKklhhijFg.0&revision=8960707587b89abdec8ecd300a740979fc16902e

To: Wayne
Wayne, maybe you can show us where to look for the binary from the above job.

Flags: needinfo?(wayne.mery)

(In reply to Wayne Mery (:wsmwk) from comment #76)

I agree, it may be possible a real fix may be Mac specific. Might also be SDK related.

Short read patch (if it really does help) may not be a workaround for everyone.

To: Wayne
Wayne, maybe you can show us where to look for the binary from the above job.

To: Wayne
Wayne, maybe you can show us where to look for the binary from the above job.

I could not figure this out. There used to be a simple link shown to the file.　Thank you.

MacOS users may want to try DEBUG build version if possible.

I am curious what will happen with the try-comm-server binary.

In the mean time,

(In reply to Alessandro Castellani (:aleca) from comment #75)

So before doing serious debugging, can you make sure that other programs on MacOS Big Sur can see the files on the remote server, and copy them and write them on the remote file system without visible errors?

I did a very simple test where I copied 10GB from my HDD to the NAS, and back from the NAS to my HDD. It was a single 8k video and the process completed without issues.
I also copied a folder with 100 raw pictures, no errors encountered.
Let me know if there's a tool or a specific workflow you want me to use.

Thank you for taking the time check this.
Given that TB 60 works and your copying works, I thikn SMB itself is working.

Users reported that up until TB 60, everything worked properly.
Magnus pointed to a possible regression range in Comment 13, I don't know if that could be helpful.

I am browsing but nowthing stands out so far.

Thank you so much for looking into this.

You are welcome and if you can tinker with the OSX binary mentioned in the Wayne's post (and if possible to run the debug version from TTY console to leave a trail of errors on the tty console, that is super.)

FYI, there was a Mac SDK issue that forced FF developers to downgrade after new Xcode install updated their SDK on Mac computers.
Not sure if this is relevant, but I cannot rule out SDK version issues.
It has been a problem that there do not seem to many MacOS users among the serious TB patch contributors.
mailing list: dev-platform postings.
https://groups.google.com/g/mozilla.dev.platform/c/xSTtqTrY8Z8/m/yo9M9PPdCwAJ

(In reply to ISHIKAWA, Chiaki from comment #74)

After reading the thread I realized that some earlier versions do connect to NAS and work as expected.
Very strange.
It is possible that Apple SDK may have changed ever so slightly again in terms of error code handling (assuming that there are different versions of SDK linked to the latest version of TB and the older version of TB.)

Hmm...

Dear Ishikawa-san,

TB 60.9.1. still works fine with macOS Catalina 10.15.7, with my Synology NAS.
From what I read above, TB 60.9.1. still connects fine with the NAS on Big Sur but is unusable because of invisible texts.
So far I did not experience file access issues on my NAS with any other software.

I really appreciate your efforts!!!

As above.

THIS IS A LONG COMMENT TRAIL - TO RECAP: The problems accessing a profile stored on a NAS from a Mac started with an upgrade to T-bird without any change in MacOS. Aside from the problems with T-bird, I have never had any problems accessing the NAS from any other program (or from Finder or Path Finder file browsers) in any version of MacOS, including the latest (Big Sur - v11.0.1). As I documented in Comment #12, I followed daily versions of T-bird and it failed at 67.0a1 (2019-02-28) (64-bit), and for all subsequent versions until the present. The trick is to discover WHAT changed in that version from the previous versions that worked fine [clearly easy to say and much harder to do!].

The latest problems with invisible texts is a NEW issue, apparently unrelated to this bug, and occurs with version 60.9.1, [at least] while accessing a profile located on an NAS, and after an upgrade to MacOS Big Sur. It may also occur if the profile is located on the Mac, but I haven't tried.

Important to note: There have never been any problems with any version of T-bird (I am currently running T-bird 78.5.0 (64-bit), while accessing the same profile on the NAS from a PC running Windows 10, up to and including the latest version (10.1.19041).

(In reply to mike.derby from comment #80)

Important to note: There have never been any problems with any version of T-bird (I am currently running T-bird 78.5.0 (64-bit), while accessing the same profile on the NAS from a PC running Windows 10, up to and including the latest version (10.1.19041).

Can you try the debug build of OSX version the C-C TB available at

    https://treeherder.mozilla.org/jobs?repo=try-comm-central&selectedTaskRun=L80Ig-WuRWW5sKklhhijFg.0&revision=8960707587b89abdec8ecd300a740979fc16902e
    click the "B" (for binary) next to "OS X Cross Compiled shippable opt"

    in the black header of the section below, click "artifacts"
    find target.dmg - thus the download link is https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/HaeEOi3kRw-vZx-LIOgEfw/runs/0/artifacts/public/build/target.dmg

MacOS users may want to try DEBUG build version if possible.

I am curious what will happen with this binary when the profile on the remote NAS CIFS/SMB file system is accessed by TB.
Please run this from terminal and see if you spot any strange errors in the verbose debug output.

This binary is only for testing the access to CIFS/SMB and not meant for production, but I am very curious if this binary can read the profile on remote CIFS/SMB mount in your case.

I have read that changing the parameter on the server for read/write did not have any effect in comment 72.
I mentioned that there is a routine to read JSON file and that is in M-C portion of the source tree and IF that file (I think some of the personal data is stored as JSON file in the profile) has become bigger than the
read/write packet size set on the server, then you may be in trouble. No fix for short read in C-C portion has touched that.

Important to note: There have never been any problems with any version of T-bird (I am currently running T-bird 78.5.0 (64-bit), while accessing the same profile on the NAS from a PC running Windows 10, up to and including the latest version (10.1.19041).

Windows10 system call for read access (to files locally on remote server) has this automatic re-reading after a short read built-in.
So it is handled under the hood, so to speak. That is why we don't see Windows users complain.
Only non Windows users, which mean MacOS and Linux users mostly are affected by this. (Other systems may also suffer possibly.)

BTW, BLACK color issue seems to have plagued MacOS users for a while.: I have found posts such as
https://support.mozilla.org/en-US/questions/1297337
I am sure there must be a bugzilla about this issue. I will focus on the read issue against remote CIFS/SMB.

Flags: needinfo?(mike.derby)

In comment #12, following a suggestion from Magnus Melin, I tested a series of sequential daily versions and reported the following:

   **So there is a change in the app contained within the DMG files from version 66.0a1 (2019-01-28) (64-bit) to version 67.0a1 (2019-02-01) (64-bit)**

Since 60.0.9 (as well as version 66.0a1 (2019-01-28) (64-bit)) has no problems accessing a profile on the NAS, and we know that version 67.0a1 (2019-02-01) (64-bit) is broken, can't someone familiar with coding simply run a file compare between the two versions, identify the changes, and then focus on those changes that might have resulted in T-bird not working? Unless there were many, many changes made between daily versions, I can't see it taking more time than it took me to identify the point at which the failure occurred, especially since most changes would presumably be irrelevant.

I would think this might be more productive than trying to guess at a cause for the failure, even if we are making very educated and insightful guesses.

Flags: needinfo?(mike.derby)

The likely cause I'd imagine is one of these:

https://hg.mozilla.org/mozilla-central/rev/86b7743d7a65558916f5bcdeded055c3ea4a32ec Dave Townsend — Bug 1463198: Submit telemetry whenever the downgrade UI is shown. r=froydnj, datareview=chutten
https://hg.mozilla.org/mozilla-central/rev/250089b693374edda20126b5ae7f6e7dd282c817 Dave Townsend — Bug 1455707: Detect when running an older version than previously ran with the selected profile. r=froydnj, r=mconley, r=Gijs
https://hg.mozilla.org/mozilla-central/rev/a5ab8fa035ce41c1967caeb4f37aef1fc047f252 Dave Townsend — Bug 1518632: Show the first-run experience for users that get pushed to a new profile. r=Gijs, r=flod, r=stomlinson
https://hg.mozilla.org/mozilla-central/rev/28e889fa43224adcc585bdccbe37a35307796a09 Dave Townsend — Bug 1522934: Add telemetry data to record what happened during profile selection at startup. r=froydnj, datareview=chutten
https://hg.mozilla.org/mozilla-central/rev/58babf220962945b5ed8b4af5309d81eb8376571 Dave Townsend — Bug 1474285: Implement dedicated profiles per install. r=froydnj, r=Gijs
https://hg.mozilla.org/mozilla-central/rev/d3b849c06ebc602a15d086f3778f92880ca4f0fd Dave Townsend — Bug 1322797: Replace selectedProfile with currentProfile and fix defaultProfile. r=froydnj, r=flod

Would be interesting to also know if compiling with MOZ_DEDICATED_PROFILES false makes it work.

Would be interesting to also know if compiling with MOZ_DEDICATED_PROFILES false makes it work.

I can try that, can you specifically tell me what do I have to do?

I think you just put export MOZ_DEDICATED_PROFILES=0 in your .mozconfig

error:

mozbuild.configure.options.InvalidOptionError: MOZ_DEDICATED_PROFILES=0 can not be set by mozconfig.
Values are accepted from: implied

I'm unsure whether this info will be of value or not, so either use or ignore it.

In the process of trying some of the suggestions, I suddenly lost all of my local [stored] files from January 2020 to the present. When I examined the Profile, I found multiple instances of the local folders and over a couple of days managed to manually recover all of those stored emails up to the present. IMPORTANT NOTE to Mac users who make too many assumptions: Time Machine does NOT back up networked drives, even those always mounted at startup! I then converted the emails in the local folders up to the end of 2019 to PDFs and made the local folder much, much smaller (I thought perhaps that excessive size might be interfering with accessing the NAS. Bottom line: Smaller size didn't make any difference, but it took awhile to verify that. When I started T-bird on the Mac, it started up in 78.5.1 (apparently I missed one of those insistent update requests). I decided that might be useful, and installed both 60.9.1 and 78.5.1 on the Mac and then tried to create profiles on the NAS.

Remember, my Mac is now running Big Sur (OS 11.0.1).

I created separate Mac and NAS profiles in each location for each T-bird version and got the following results:

60.9.1 accessed its local Mac profile without any problems, 
but had a totally unresponsive, gray start window with a blank message window when accessing its NAS profile .
 
78.5.1 also accessed its local Mac profile OK (although I couldn't figure out how to get mail filters to transfer from the old profile), 
but its profile on the NAS produced a blank window without functional menu choices

Not sure any of this is helpful, but I did get my emails backed up in case I move to another program

Images follow...

Attached image 60.9.1 on MAC.png —
Attached image 60.9.1on NAS.png —
Attached image 78.5.1 on MAC.png —
Attached image 78.5.1 on NAS.png —

Mike,
You are still seeing this with version 91?

status-thunderbird_esr78: affected → wontfix
status-thunderbird_esr91: --- → affected
Flags: needinfo?(mike.derby)

Although I'm not Mike ;-) I can confirm that I see no changes unfortunately (TB 91.2.0, macOS 10.15.7).
I'd be VERY happy if this could be fixed and I could upgrade from TB 60.9.1 which is still working fine.

Unfortunately this is beyond my skill level.
I think we need someone well versed in C++ that can see what's going on.

I'm pinging BenC to see if he has any capacity to check this.
I'm more than happy to test any patch as I've recreated the issue consistently with my setup.

Assignee: alessandro → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(benc)

Hi guys.

I'm sorry to report that I temporarily gave up on using Tbird on the NAS and have just located the profile on my PC. That is hardly optimal, but as a result i can't comment on how well the latest version on the MAC works with a NAS. The last time I checked last summer (early August), nothing had changed. However, Apple seems to have a VERY buggy version of OS 11. It keeps updating and we are now up to 11.6, so I was reluctant to invest too much time until it became more stable. I have been evaluating other clients that could replace Tbird, with access from both a MAC & PC to files on the NAS, but none seem to have the features and flexibility of Tbird.

Solving this problem is way past my skill set, but if someone has a possible solution, I'm willing to see if it works with my system

Flags: needinfo?(mike.derby)

I re-read the log in .rtf format attachment.
I found the following.


problem	18:40:15.644198+0200	accountsd	Unentitled access by client 'thunderbird-bin' (selector: accountsWithAccountType:handler:)
fehler	18:40:15.644613+0200	thunderbird-bin	"Error returned from daemon: Error Domain=com.apple.accounts Code=9"
problem	18:40:15.645636+0200	accountsd	Unentitled access by client 'thunderbird-bin' (selector: accountsWithAccountType:handler:)
fehler	18:40:15.645720+0200	thunderbird-bin	"Error returned from daemon: Error Domain=com.apple.accounts Code=9"
standard	18:40:15.661048+0200	thunderbird-bin	Will add prepared store without migration (path: (null))
standard	18:40:15.661175+0200	thunderbird-bin	Will add SQLite store with options: <private> <private>
standard	18:40:15.668562+0200	thunderbird-bin	Did add SQLite store
standard	18:40:15.668606+0200	thunderbird-bin	Did add prepared store without migration (path: (null))
standard	18:40:15.725213+0200	thunderbird-bin	0x123fd4ec0: Posting CNCDContactStoreDidChangeNotification because accounts changed
standard	18:40:15.733047+0200	thunderbird-bin	Will add prepared store without migration (path: (null))
standard	18:40:15.733165+0200	thunderbird-bin	Will add SQLite store with option

I am not an expert on MacOS, but there seems to be a security-related issue to the handling of SQLite database.
Note Error Domain=com.apple.accounts Code=9
And please note that it is NOT 'thunderbird' that is accessing the database, but 'thunderbird-bin'. ("-bin" is appended at the end.)

Maybe the installation script or something has forgotten to include 'thunderbird-bin' in addition to 'thunderbird' when it tried to add proper credential to the concerned binaries???
As far as the above log is concerned, it looks to me that thunderbird-bin is not allowed to touch SQLite database which I believe is the local storage for TB from reading the earlier log.

Based on the previous comment, maybe Rob knows more. When did we start notarising Mac builds, that was around 68 wasn't it?

Flags: needinfo?(rob)

It is also possible that the remote (NAS) may not recognize the proper credential (access right, or whatever) on the client side in the
client PC <---> NAS (samba?)
connection.
These have to be eliminated somehow on the NAS side (?) as well.
But it seems that these are from the client Mac, correct?

nentitled access by client 'thunderbird-bin' (selector: accountsWithAccountType:handler:)
fehler	18:40:15.644613+0200	thunderbird-bin	"Error returned from daemon: Error Domain=com.apple.accounts Code=9"
problem	18:40:15.645636+0200	accountsd	Unentitled access by client 'thunderbird-bin' (selector: accountsWithAccountType:handler:)
fehler	18:40:15.645720+0200	thunderbird-bin	"Error returned from daemon: Error Domain=com.apple.accounts Code=9"

We have the regression window (almost), so seems likely it's from the profile per install (Bug 1474285, Bug 1455707) from comment 83.

I am not an MacOS expert, but from what I read in the following URL, maybe the user experiencing the problem may need to
enable SOMETHING as noted at the end of the following post.
The following post actually talks of having to remove a service MANUALLY from apple security framework even after the user moves the application to Trash.: '"uninstalling" applications and needing to "manually" remove them from apple security infrastructure.'

If that is the case, then maybe one needs to enable the access to network file system (or SOMETHING) for thunderbird (or thunderbird-bin) under MacOS. Definitely, it has something to do with this new feature called |accountsd|.
It is like having to enable access to resources on my smartphone for apps to access local documents, photos, or contact addresses, etc., I suppose.

We need more Mac-savvy developers here. (MacOS-savvy as opposed to iOS).

My reading of the following post suggests that there IS a security setting for changing access permission to remote file system (!)

https://apple.stackexchange.com/questions/374332/does-full-disk-access-include-access-to-files-and-folders-privacy-settings

Full Disk Access (SystemPolicyAllFiles) covers all protected file locations including the new ones you mention. From [PrivacyPreferencesPolicyControl.Services]  ( https://developer.apple.com/documentation/devicemanagement/privacypreferencespolicycontrol/services):
... omission ...
SystemPolicyNetworkVolumes Allows the application to access files on network volumes.  <---- THIS
... omission ...

So I think this is the root cause of the problem.

From https://developer.apple.com/documentation/devicemanagement/privacypreferencespolicycontrol/services

SystemPolicyNetworkVolumes
[PrivacyPreferencesPolicyControl.Services.Identity]

Allows the application to access files on network volumes.

Can Alexander and Alessandro try adding this permission, Full Disk Access, to |Thunderbird| from Security & Privacy dialog as in
https://apple.stackexchange.com/questions/396300/siri-accounts-faults-in-mac-os-catalina-10-15-6-process-demon-faults-accoun
[That particular blog was discussing the removal of the permission. You have to do the reverse.
And the permission you need to grant is I think "Full Disk Access (SystemPolicyAllFiles) ".]
As MacOS app, I don't think there would be an entry for thunderbird-bin, but if so, please add it to this binary as well, and see how situation may change?

I have an uneasy feeling about "thunderbird" vs "thunderbird-bin", but the latter must be invoked from the former and usually the access privilege is inherited for application developer's benefit and so...

Flags: needinfo?(apdus)
Flags: needinfo?(alessandro)

Mike can you check if the comment 102 applies to your case as well?

Flags: needinfo?(mike.derby)
Attached image security.png —

I updated the security options for all my versions of thunderbird, and I also included the *-bin executable from within daily, but no luck.
The problem persists.

Maybe it's a silly question, but is there a way to request/grant that SystemPolicyNetworkVolumes policy from code? Maybe in an INI file or something like that.

Flags: needinfo?(alessandro)

As requested by Ishikawa-san, I can report that on my Mac the "Full Disk Access" was set already for Thunderbird, see attached image. I can't remember if I set that manually some day, if so it was quite a while ago. No visible entry for 'thunderbird-bin'. So although this sounded great, I'm afraid it's something else...
Side note, not sure if this is relevant: In order to keep a working solution on my machine and being able to test new versions, I have two versions of TB installed: the TB60 called "Thunderbird 60" and the newer test version just unchanged "Thunderbird". Since "Thunderbird 60" is not specifically listed in the permissions list, I have no idea how it accesses the NAS anyhow. Unless MacOS somehow does not distinguish between the two TB processes, in which case the bug must be again somewhere in the new code...?!?

Flags: needinfo?(apdus)

(In reply to Alessandro Castellani [:aleca] from comment #104)

Created attachment 9246932 [details]
security.png

I updated the security options for all my versions of thunderbird, and I also included the *-bin executable from within daily, but no luck.
The problem persists.

Maybe it's a silly question, but is there a way to request/grant that SystemPolicyNetworkVolumes policy from code? Maybe in an INI file or something like that.

Thank you for checking.

I believe there is a way to request the SystemPolicyNetworkVolumes from the code. That has to be done by MacOS-specific code targeting OS 10.1.x or later, I think.

So I have to retract my premature guess and think of other reasons. Alexander's comment 105 suggests something very strange.

(In reply to Alexander from comment #105)

Created attachment 9246933 [details]
Mac Permissions - not changed, not working.png

As requested by Ishikawa-san, I can report that on my Mac the "Full Disk Access" was set already for Thunderbird, see attached image. I can't remember if I set that manually some day, if so it was quite a while ago. No visible entry for 'thunderbird-bin'. So although this sounded great, I'm afraid it's something else...
Side note, not sure if this is relevant: In order to keep a working solution on my machine and being able to test new versions, I have two versions of TB installed: the TB60 called "Thunderbird 60" and the newer test version just unchanged "Thunderbird". Since "Thunderbird 60" is not specifically listed in the permissions list, I have no idea how it accesses the NAS anyhow. Unless MacOS somehow does not distinguish between the two TB processes, in which case the bug must be again somewhere in the new code...?!?

Thank you for testing.

Now this gets interesting.
So TB60 works from the same PC to access the profile on NAS. This in a sense precludes the problem of CIFS/Samba mount somehow.
Hmm...

(In reply to Geoff Lankow (:darktrojan) from comment #97)

Based on the previous comment, maybe Rob knows more. When did we start notarising Mac builds, that was around 68 wasn't it?

Post 68 I think, but definitely before 78.

Flags: needinfo?(rob)

I now have a theory, but not having a hardware where MacOSX runs does not help much.

The SDK linked with later version of TB probably has additional privilege check built-in.
The older binary probably is given a somewhat loose control because if OS tightens the grip on security suddenly many statically-linked binaries simply stop working and Apple will have to deal with angry users.
But newer binaries linked with new SDK dynamically may have the stricter access control imposed on them.
The statically linked binary may not.

We need a developer with MacOSX - capable hardware to look into this. I think with the proper hardware and right version of the OSX, AND
a remote Samba server (well actually getting all this ready to go may be difficult), the debugging should proceed fast.

Just a wild guess. But unless something like this is happening, I can't see why TB60 works and later TB doesn't.
TB60 works means CIFS/Samba mount at least is working well.

(In reply to Alessandro Castellani [:aleca] from comment #104)

Created attachment 9246932 [details]
security.png

I updated the security options for all my versions of thunderbird, and I also included the *-bin executable from within daily, but no luck.
The problem persists.

Maybe it's a silly question, but is there a way to request/grant that SystemPolicyNetworkVolumes policy from code? Maybe in an INI file or something like that.

Alessandro, sometimes manuals are not quite correct.
Can you check the permission for "Files and Folders" for the binaries just in case?
If my reading of Apple document is correct, they don't matter, but we may have to give the permission explicitly if the document is incorrect?

Flags: needinfo?(alessandro)

(In reply to Magnus Melin [:mkmelin] from comment #44)

For some reason you end up at https://searchfox.org/mozilla-central/rev/ac142717cc067d875e83e4b1316f004f6e063a46/toolkit/components/xulstore/old/XULStore.jsm#66, but I don't see any clues to why.

Just after the error from .jsm, we see an error

JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
[15050, Main Thread] WARNING: '!mLocalStore', file /builds/worker/checkouts/gecko/dom/xul/XULPersist.cpp, line 168
[15050, Main Thread] WARNING: NS_ENSURE_TRUE(root) failed: file /builds/worker/checkouts/gecko/layout/base/nsDocumentViewer.cpp, line 2910
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
[15050, Main Thread] WARNING: '!mLocalStore', file

I think the line number has changed slightly, but the following is where mLocalStore error check is.
https://searchfox.org/comm-central/source/mozilla/dom/xul/XULPersist.cpp#169


  // Add all of the 'persisted' attributes into the content
  // model.
#ifndef MOZ_NEW_XULSTORE
  if (!mLocalStore) {
    mLocalStore = do_GetService("@mozilla.org/xul/xulstore;1");
    if (NS_WARN_IF(!mLocalStore)) {
      return NS_ERROR_NOT_INITIALIZED;
    }
  }
#endif

So can it mean that we have different C++ macro setup between TB60 and later versions?
MOZ_NEW_XULSTORE is not defined for later vesion and thus the check?

In any case, we can't even find the profile directory path to start with. That is bad.

In the Console-Errors and problems.rtf, I see

fehler	18:38:01.093549+0200	mdworker_shared	All kCFPreferencesCurrentUser domains in this process will be volatile, because homeDirPath starts with /var/empty

that is, a user's home directory starts with /var/empty and thus not properly set up. Can this be possible? I have a feeling that this may lead to the next error and possible remote file system access error, but again I am not an expert of MacOSX.

My educated guess is that /var/empty is invalid for home directory and this leads to the NSCocoaErrorDomain because "No such file or directory" (probasbly for the home directory), and

fehler	18:38:01.171339+0200	mdworker_shared	All kCFPreferencesCurrentUser domains in this process will be volatile, because homeDirPath starts with /var/empty
fehler	18:38:01.558253+0200	mds	copy resource property err Error Domain=NSCocoaErrorDomain Code=260 UserInfo={NSURL=<private>, NSFilePath=<private>, NSUnderlyingError=0x7fe68183d5f0 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}} url <private>
fehler	18:38:01.558331+0200	mds	unexpected nil uti-type; Please clone <rdar://problem/18605177> with- <private> - <private>
fehler	18:38:16.818365+0200	fileproviderd	[ERROR] <FPDExtensionSession(com.apple.CloudDocs.MobileDocumentsFileProvider): 0x7fc73160f020 requests{indexOneBatchInDomain:completionHandler: (2020-09-06 16:38:16 +0000)}, extenders{}> took too long to perform: indexOneBatchInDomain:completionHandler:, killing it...

Actually, this "; Please clone <rdar://problem/18605177> with- <private> - <private>" suggests some type of authentication error.
See https://support.cocoatech.com/discussions/problems/40691-authentication-fails-to-move-or-create-files-and-folders

The only reason I think the newer version of TB bumps into this authentication error and the older version of TB didn't is the use of different SDK.
Instead of implementing the tighter security into the kernel and making older binary unusable in one sweep, Apple must have devised the graceful period when the tight security is imposed by dynamically linked user space library so that the developers will have some leeway while they adopt the newer security model. I think the next major version will put the security into kernel and all the binaries that do not accommodate the newer security model won't run at all.

This is all I can say for now from the viewpoint of an occasional patch contributor who hacks code under Linux most of the time.

I'm glad to see all of the current attention to this bug, but I'd remind people that my original problem concerned a sudden inability to use an NAS to store a profile.

This problem appeared with an upgrade to Tbird while:
a) the MAC OS DID NOT CHANGE
b) the NAS DID NOT CHANGE

Furthermore, if one reverted to the old Tbird version, the system worked fine, while the Tbird upgrade version did not work indicating that there was a change within the Tbird code with that upgrade version (SEE COMMENT #12, #80, #82). We seem to have gotten away from looking for a change within the Tbird code that was introduced with that upgrade.

Later, I had a second problem following an upgrade to MACOS (Big Sur) and involved problems with displayed formatting (SEE COMMENT #58). Some of the recent discussion may be relevant to that, but, as I noted earlier, all it did for me was complicate troubleshooting my original problem.

Flags: needinfo?(mike.derby)

Comment 2: the platform OS was MacOS 10.15.2.
Comment 12: the change seems to have been introduced between 66.0a1 (2019-01-28) (64-bit) to version 67.0a1 (2019-02-01) (64-bit).

Was the compiler and SDK, i.e., binary toolchain switched in this time frame?
I wonder how one can know.

Can you check the permission for "Files and Folders" for the binaries just in case?
If my reading of Apple document is correct, they don't matter, but we may have to give the permission explicitly if the document is incorrect?

Sorry, I don't think I understand this request.
What do you want me to check?

Flags: needinfo?(alessandro)

(In reply to Alessandro Castellani [:aleca] from comment #114)

Can you check the permission for "Files and Folders" for the binaries just in case?
If my reading of Apple document is correct, they don't matter, but we may have to give the permission explicitly if the document is incorrect?

Sorry, I don't think I understand this request.
What do you want me to check?

Sorry, I was not clear enough.
In the security & privacy dashboard, "Files and Folders" entry exists.
I wonder if you can see any changes when you toggle the settings for thunderbird* binaries.
Not that I have high hope here, but just in case Apple doc is not correct, it may be worth a try.

(In reply to Alessandro Castellani [:aleca] from comment #94)

I'm pinging BenC to see if he has any capacity to check this.

Sorry, I've been reading through the comments so far, but I'm rather lost on all the mac-specifics :-(
NI me again if you need a fresh set of eyes and I'll set aside some time to wade about in apple documentation!
(I don't currently have a mac available to debug on, unfortunately)

Flags: needinfo?(benc)

Wayne, I think it is a matter of finding a developer with a MacOS machine.
To be frank, if a developer runs a debug version, maybe he/she can figure this out rather quickly.

Do you know anyone who has a MacOS PC and work on TB code?

Losing a user base on one popular architecture is not very nice in terms of visibility for TB as a whole, and thinking of users who need to find a viable alternative...

Flags: needinfo?(vseerror)

m_kato, do you have experience with Mac SDK / networking?
Reference: comment 99, comment 109, comment 111?

Flags: needinfo?(vseerror) → needinfo?(m_kato)
Blocks: tb-mac
Whiteboard: DUPEME

(In reply to mike.derby from comment #112)

I'm glad to see all of the current attention to this bug, but I'd remind people that my original problem concerned a sudden inability to use an NAS to store a profile.

This problem appeared with an upgrade to Tbird while:
a) the MAC OS DID NOT CHANGE
b) the NAS DID NOT CHANGE

Furthermore, if one reverted to the old Tbird version, the system worked fine, while the Tbird upgrade version did not work indicating that there was a change within the Tbird code with that upgrade version (SEE COMMENT #12, #80, #82). We seem to have gotten away from looking for a change within the Tbird code that was introduced with that upgrade.

THANK YOU for pointing this out again!!!
As a user, I kind of have the impression that some fellows are quickly eager to pinpoint the issue at Apple and/or users to find reasons to not follow up (and in many cases they may be right; I had my share of disappointments with other software), but the circumstances here really look like some issue in the TB code. I mean, if TB is to be kept alive for the Apple platform, some developer must have at least a recent Mac Mini available, and there is definitely also a Synology NAS around, purchased above about a year ago. But nothing happens :-(
Now again, after some quick exchange for a few days it seems like silence settled in again ...
I really appreciate the efforts and energy of all the developers, but the missing progress for 2 years now let's me really frustrated and more sooner than later will push me (and others) away to solutions with are working.

I'm not trying to minimize the work involved, but has anyone actually tried to compare the last working version to the next (updated) NON-working version? As I last pointed out, we know exactly when this happened – so the question remaining is, what changed with the update. At this point, speculating on theoretical reasons doesn't seem very productive: after all, this change happened over 2 YEARS ago and lots of speculation has not produced a solution.

The coders involved in that broken update must have left some notes as to their changes and what they were intended to do. It would seem the simplest (but again, I realize very tedious and time-consuming) approach is to compare the working against the non-working version until the problem is located. With every month/year that passes, we get farther and farther away from that working version and much more likely to have introduced further changes that break the system in even new ways.

I'm just a user (the last coding I did was very long ago with Fortran IV, so that gives you some perspective). I appreciate that the coders working on this are doing it for love of the challenge, but although I really like Thunderbird, it's only usable on one of my computers now and the inconvenience has forced me to start seriously auditioning alternatives.

Please, if anyone wants the challenge, please fix this before I am forced to move to another, less fit-for-purpose alternative!

(In reply to Alexander from comment #119)

(In reply to mike.derby from comment #112)

I'm glad to see all of the current attention to this bug, but I'd remind people that my original problem concerned a sudden inability to use an NAS to store a profile.

This problem appeared with an upgrade to Tbird while:
a) the MAC OS DID NOT CHANGE
b) the NAS DID NOT CHANGE

Furthermore, if one reverted to the old Tbird version, the system worked fine, while the Tbird upgrade version did not work indicating that there was a change within the Tbird code with that upgrade version (SEE COMMENT #12, #80, #82). We seem to have gotten away from looking for a change within the Tbird code that was introduced with that upgrade.

THANK YOU for pointing this out again!!!
As a user, I kind of have the impression that some fellows are quickly eager to pinpoint the issue at Apple and/or users to find reasons to not follow up (and in many cases they may be right; I had my share of disappointments with other software), but the circumstances here really look like some issue in the TB code. I mean, if TB is to be kept alive for the Apple platform, some developer must have at least a recent Mac Mini available, and there is definitely also a Synology NAS around, purchased above about a year ago. But nothing happens :-(
Now again, after some quick exchange for a few days it seems like silence settled in again ...
I really appreciate the efforts and energy of all the developers, but the missing progress for 2 years now let's me really frustrated and more sooner than later will push me (and others) away to solutions with are working.

Alexander,
In the post of problem.rtf and console error messages, I found a bunch of disturbing messages and wrote in comment 111

In any case, we can't even find the profile directory path to start with. That is bad.

In the Console-Errors and problems.rtf, I see

fehler	18:38:01.093549+0200	mdworker_shared	All kCFPreferencesCurrentUser domains in this process will be volatile, because homeDirPath starts with /var/empty

that is, a user's home directory starts with /var/empty and thus not properly set up. Can this be possible? I have a feeling that this may lead to the next error and possible remote file system access error, but again I am not an expert of MacOSX.

My educated guess is that /var/empty is invalid for home directory and this leads to the NSCocoaErrorDomain because "No such file or directory" (probasbly for the home directory), and

fehler	18:38:01.171339+0200	mdworker_shared	All kCFPreferencesCurrentUser domains in this process will be volatile, because homeDirPath starts with /var/empty
fehler	18:38:01.558253+0200	mds	copy resource property err Error Domain=NSCocoaErrorDomain Code=260 UserInfo={NSURL=<private>, NSFilePath=<private>, NSUnderlyingError=0x7fe68183d5f0 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}} url <private>
fehler	18:38:01.558331+0200	mds	unexpected nil uti-type; Please clone <rdar://problem/18605177> with- <private> - <private>
fehler	18:38:16.818365+0200	fileproviderd	[ERROR] <FPDExtensionSession(com.apple.CloudDocs.MobileDocumentsFileProvider): 0x7fc73160f020 requests{indexOneBatchInDomain:completionHandler: (2020-09-06 16:38:16 +0000)}, extenders{}> took too long to perform: indexOneBatchInDomain:completionHandler:, killing it...

Actually, this "; Please clone <rdar://problem/18605177> with- <private> - <private>" suggests some type of authentication error.
See https://support.cocoatech.com/discussions/problems/40691-authentication-fails-to-move-or-create-files-and-folders

The only reason I think the newer version of TB bumps into this authentication error and the older version of TB didn't is the use of different SDK.

I am not familiar with NAS you are using, but can there be any possibility that the user account you are using for TB
do have home directory ("homeDirPath") properly set up
case 1 - under Mac OSX [this I am tempted to think "yes", otherwise other programs may not work.]
case 2 - under NAS (I am not even sure if NAS has a notion of home directory ("homeDirPath") of a user account, but the strange message in .rtf suggests newer TB fails to find the home directory [presumably on NAS] through the interaction of NAS and authentication process (is my best educated guess).

Can you check the above?

Case 2 could be that authentication somehow fails with new version silently? (I wonder why)
and thus lower layer code assumes that /var/empty is the make-shift entry and TB is working with this bogus homeDirPath.

Looking for "/var" in searchfox ( https://searchfox.org/comm-central/search?q=%2Fvar%2F&path=&case=false&regexp=false )
and then looking for "mac" in that page, I found references to sandboxing.
I wonder if sandboxing has anything to do with the observed bug.

I just installed the 91.5.1 update on my Mac to see whether anything had resolved over the past two years.

IT HAS NOT!

Current setup: Mac mini running MacOS 12.2; Synology DS218+ running DSM 7.0.1-42218; QNAP TS-253A running 5.0.0.1891; Windows 11 PC running 22000.434; Windows 10 PC running 19044.1466, all connected by ethernet.

Using Tbird 91.5.1 with a profile.ini/profile stored on a directly connected drive on my mac, I have a fully functioning installation.

If, however, I move the profile to either a Synology DS218+ NAS, OR a QNAP TS-253A NAS, OR a PC running Windows 11 or 10, mapping the location to connect at startup (so that it is continuously available to local programs), and then pointing the Profile.ini at the mapped location, Tbird loads with blank windows as shown above in comments #34 and #91. NOTE: this happens with the profile on BOTH networked NAS and Windows PCs.

The Tbird profile folder on either NAS or on the Windows 11 PC is accessible through both Mac Finder and Windows File Explorer, and can be edited, deleted, etc., so the mac can see it and manipulate it, just the same as the PC.

With regard to comment #111, the coding analysis is beyond my abilities. However, even though Tbird clearly has issues, note that the Mac Finder (as well as other applications on the Mac) is able to recognize and access files on either NAS (and on either of the 2 Windows PCs).

Again, it is very clear that the change from version 66.0a1 (2019-01-28) (64-bit) to version 67.0a1 (2019-02-01) (64-bit) broke the ability of Tbird on the Mac to access a profile on either a Synology or QNAP NAS (and now I can also add OR a networked Windows PC). So, this appears a simple problem of network access.

What changed between those two versions that now prevents Tbird from accessing files that other Mac applications seem able to access?

I initially spent a lot of time identifying the precise version where the change first appeared, but that does not seem to have been very useful, perhaps because not everyone has ready access to a NAS. I have now spent even more time checking the latest version of Tbird for the Mac and testing access to profiles on NAS from the 2 major manufacturers as well as on networked Windows PCs.

It appears that you don't need a NAS to look at this ⎻ it would appear that if you just have a Mac and a PC you are good to go. Perhaps this understanding will allow more people to tackle the problem.

It has been 2 years, people! -> 2 years!!! <- It's time for a solution.

(In reply to ISHIKAWA, Chiaki from comment #121)

(In reply to Alexander from comment #119)

(In reply to mike.derby from comment #112)

I'm glad to see all of the current attention to this bug, but I'd remind people that my original problem concerned a sudden inability to use an NAS to store a profile.

This problem appeared with an upgrade to Tbird while:
a) the MAC OS DID NOT CHANGE
b) the NAS DID NOT CHANGE

Furthermore, if one reverted to the old Tbird version, the system worked fine, while the Tbird upgrade version did not work indicating that there was a change within the Tbird code with that upgrade version (SEE COMMENT #12, #80, #82). We seem to have gotten away from looking for a change within the Tbird code that was introduced with that upgrade.

THANK YOU for pointing this out again!!!
As a user, I kind of have the impression that some fellows are quickly eager to pinpoint the issue at Apple and/or users to find reasons to not follow up (and in many cases they may be right; I had my share of disappointments with other software), but the circumstances here really look like some issue in the TB code. I mean, if TB is to be kept alive for the Apple platform, some developer must have at least a recent Mac Mini available, and there is definitely also a Synology NAS around, purchased above about a year ago. But nothing happens :-(
Now again, after some quick exchange for a few days it seems like silence settled in again ...
I really appreciate the efforts and energy of all the developers, but the missing progress for 2 years now let's me really frustrated and more sooner than later will push me (and others) away to solutions with are working.

Alexander,
In the post of problem.rtf and console error messages, I found a bunch of disturbing messages and wrote in comment 111

In any case, we can't even find the profile directory path to start with. That is bad.

In the Console-Errors and problems.rtf, I see

fehler	18:38:01.093549+0200	mdworker_shared	All kCFPreferencesCurrentUser domains in this process will be volatile, because homeDirPath starts with /var/empty

that is, a user's home directory starts with /var/empty and thus not properly set up. Can this be possible? I have a feeling that this may lead to the next error and possible remote file system access error, but again I am not an expert of MacOSX.

My educated guess is that /var/empty is invalid for home directory and this leads to the NSCocoaErrorDomain because "No such file or directory" (probasbly for the home directory), and

fehler	18:38:01.171339+0200	mdworker_shared	All kCFPreferencesCurrentUser domains in this process will be volatile, because homeDirPath starts with /var/empty
fehler	18:38:01.558253+0200	mds	copy resource property err Error Domain=NSCocoaErrorDomain Code=260 UserInfo={NSURL=<private>, NSFilePath=<private>, NSUnderlyingError=0x7fe68183d5f0 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}} url <private>
fehler	18:38:01.558331+0200	mds	unexpected nil uti-type; Please clone <rdar://problem/18605177> with- <private> - <private>
fehler	18:38:16.818365+0200	fileproviderd	[ERROR] <FPDExtensionSession(com.apple.CloudDocs.MobileDocumentsFileProvider): 0x7fc73160f020 requests{indexOneBatchInDomain:completionHandler: (2020-09-06 16:38:16 +0000)}, extenders{}> took too long to perform: indexOneBatchInDomain:completionHandler:, killing it...

Actually, this "; Please clone <rdar://problem/18605177> with- <private> - <private>" suggests some type of authentication error.
See https://support.cocoatech.com/discussions/problems/40691-authentication-fails-to-move-or-create-files-and-folders

The only reason I think the newer version of TB bumps into this authentication error and the older version of TB didn't is the use of different SDK.

I am not familiar with NAS you are using, but can there be any possibility that the user account you are using for TB
do have home directory ("homeDirPath") properly set up
case 1 - under Mac OSX [this I am tempted to think "yes", otherwise other programs may not work.]
case 2 - under NAS (I am not even sure if NAS has a notion of home directory ("homeDirPath") of a user account, but the strange message in .rtf suggests newer TB fails to find the home directory [presumably on NAS] through the interaction of NAS and authentication process (is my best educated guess).

Can you check the above?

Case 2 could be that authentication somehow fails with new version silently? (I wonder why)
and thus lower layer code assumes that /var/empty is the make-shift entry and TB is working with this bogus homeDirPath.

Looking for "/var" in searchfox ( https://searchfox.org/comm-central/search?q=%2Fvar%2F&path=&case=false&regexp=false )
and then looking for "mac" in that page, I found references to sandboxing.
I wonder if sandboxing has anything to do with the observed bug.

Dear Ishikawa-san,

I am afraid I only understand half of what you're writing, however I have tested with Admin rights, incl. logging into the NAS with Admin rights. No noticeable change to working with user rights. If I misunderstood, please give me better instructions what you want me (and others) to do.

Looking at comment #122 I find it very interesting that accessing a profile on a Windows system also does not work, so to me it verifies that it's really a network access issue, not related to a NAS specifically.

I don't see this as significantly improving TB's capability on Mac, so removing the meta.

No longer blocks: tb-mac
Flags: needinfo?(m_kato)

After receiving the change notifications for bug 1578539, I tested once again if my original issue was solved (opening TB profiles stored on a (Synology-)NAS), and SURPRISE: it worked again!!! Since my Mac is old, I can only confirm for Mac OS 12.7.2 with TB 115.6.0, so it would be helpful if others can test and confirm as well for modern Macs!

Attachment #9386135 - Attachment is obsolete: true

Mike, can you still reproduce it?

Flags: needinfo?(mike.derby)

BUG SUMMARY: When I first started using Thunderbird, it could access a profile located on a NAS from both Windows and MACOS. After an update to Thunderbird for MACOS (see above for details), MACOS Thunderbird could no longer access the NAS profile, even though Thunderbird on Windows remained able to access it. Furthermore, Thunderbird on MACOS could also not see a profile stored on a Windows computer connected by ethernet or WiFi, so it seemed as if MACOS Thunderbird had lost the ability to connect to any profile not located on a local drive.

After more than a year without a solution, I lost faith that the problem would ever be resolved and stopped routinely checking whether the latest version of Thunderbird had corrected the problem. Recently, however, I did check the latest version of Thunderbird available for MACOS and discovered that the issue had been resolved.

Since the time I reported the issue resolved (that report apparently did not get included in this chain – my bad), Thunderbird on BOTH Windows 11 and MACOS (currently version 14.4.1) have consistently accessed a NAS profile.

As a result, I believe THE ISSUE IS CURRENTLY RESOLVED.

I would point out, however, that if no one knows WHY it is now resolved or WHY it got broken in the first place, there is no guarantee that it will not break again with a future update. I spent some time to identify the exact update when the issue arose, and over the past 4 years, I have consistently asked for a coder to compare the last version that worked with the first version that did not work to specifically identify what change might have caused the problem. I would still recommend that someone do that!

Flags: needinfo?(mike.derby)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: