1609050 - Profile on shared network drive (afp) breaks after 68.x.x Update (macOS 10.13.6)

Status: RESOLVED DUPLICATE of bug 1612414

(MailNews Core :: Networking, defect)

Description

[winkelement]

Attachment: console_log.txt

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36

Steps to reproduce:

Update Thunderbird to 68.3.1 on macOS 10.13.6.
Start Thunderbird.

Actual results:

Thunderbird starts but no folders nor Emails are shown. Menu is non-functional (nothing happens when selecting Menu->Settings for example).
Same behavior in "safe mode".
Same behavior when using a "fresh" profile.
Console shows error:
thunderbird[946]/1#12 LF=0 copy_matching Error Domain=com.apple.utilities.sqlite3 Code=11 "Failed to read sqlite_master table: Error Domain=com.apple.utilities.sqlite3 Code=3 "preparev2: [3] access permission denied" UserInfo={NSDescription=preparev2: [3] access permission denied}" UserInfo={NSDescription=Failed to read sqlite_master table: Error Domain=com.apple.utilities.sqlite3 Code=3 "preparev2: [3] access permission denied" UserInfo={NSDescription=preparev2: [3] access permission denied}}
See attached log.

Expected results:

Thunderbird should load folders and emails.

Comment 1

[winkelement]

Attachment: Screenshot

Screenshot showing "empty" application window after starting TB.

Comment 2

[winkelement]

I can confirm this now happens for every single mac in our company after TB autoupdating to 68.3.1.
The only solution so far is a downgrade to 60.9.1 and disabling autoupdate.

Comment 3

[Magnus Melin [:mkmelin] (away until Aug 10)]

Maybe bug 1578539. Does deleting global-messages-db.sqlite help?

Comment 4

[winkelement]

Unfortunately not.
When i let TB create a new Profile it seems it cannot access sqlite as all .sqlite files are 0 Bytes plus the error i posted above seems to indicate something like this.

Comment 5

[Magnus Melin [:mkmelin] (away until Aug 10)]

Since there are the "access permission denied" errors, are you sure all of the profile is writable by the user?
Are you storing profiles in a non-standard location?

Also, do you see a problem in a fresh profile? (Start with the -P arg to have the profile manager show up)

Comment 6

[winkelement]

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

Since there are the "access permission denied" errors, are you sure all of the profile is writable by the user?

Yes

Are you storing profiles in a non-standard location?

Profiles are located in the default macOS location ([username]/Library/Thunderbird/Profiles).
The user folder is a network folder mounted via afp though but that shouldn't matter (at least it didn't till now).

Also, do you see a problem in a fresh profile? (Start with the -P arg to have the profile manager show up)

Yes it makes no difference if there is an existing profile or TB creates a fresh one. When creating a fresh profile all default files are created except all .sqlite files have zeo bytes.

Comment 7

[winkelement]

*zero bytes

Comment 8

[Magnus Melin [:mkmelin] (away until Aug 10)]

(In reply to winkelement from comment #6)

Profiles are located in the default macOS location ([username]/Library/Thunderbird/Profiles).
The user folder is a network folder mounted via afp though but that shouldn't matter (at least it didn't till now).

I'm guessing that may still be the issue. Can you confirm? We had some other reports about NTLM authentication v1 and samba shares.

Comment 9

[winkelement]

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

(In reply to winkelement from comment #6)

Profiles are located in the default macOS location ([username]/Library/Thunderbird/Profiles).
The user folder is a network folder mounted via afp though but that shouldn't matter (at least it didn't till now).

I'm guessing that may still be the issue. Can you confirm? We had some other reports about NTLM authentication v1 and samba shares.

Confirm what exactly? Sorry i don't understand...

Comment 10

[Magnus Melin [:mkmelin] (away until Aug 10)]

Are you able to test that it works as it should if the profile is not in folder mounted via afp?
You could also try setting the network.auth.force-generic-ntlm-v1 preference to true and see if that helps

Comment 11

[Wayne Mery (:wsmwk)]

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

Are you able to test that it works as it should if the profile is not in folder mounted via afp?
You could also try setting the network.auth.force-generic-ntlm-v1 preference to true and see if that helps

Comment 12

[winkelement]

Sorry for the late reply!

I can confirm this bug only happens when the profile folder is located on a shared network drive (mounted via afp).
Creating a profile in the local fileystem works fine.
Using profile folders on network drives worked fine up to version 60.9.1.
Setting network.auth.force-generic-ntlm-v1 to true has no effect.

Comment 13

[winkelement]

(In reply to winkelement from comment #12)

Sorry for the late reply!

I can confirm this bug only happens when the profile folder is located on a shared network drive (mounted via afp).
Creating a profile in the local fileystem works fine.
Using profile folders on network drives worked fine up to version 60.9.1.
Setting network.auth.force-generic-ntlm-v1 to true has no effect.

Comment 14

[Alexander]

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.

Comment 15

[Wayne Mery (:wsmwk)]

Let's simplify the bug landscape by duping