搜尋 Mozilla 技術支援網站

防止技術支援詐騙。我們絕對不會要求您撥打電話或發送簡訊,或是提供個人資訊。請用「回報濫用」功能回報可疑的行為。

了解更多

Importing a "new-ish" profile

more options

Thanks, greatly, in advance, for developing and maintaining TBird. I've been active with it since at least ver. 17, and that may have been an update to the prior version already in use.

Always remember that linux systems don't get viruses. Announced as of about Sept. 19, there's a "new" one that intends to target linux systems. On Sept. 23, my main LM 21 (kernel version -86?) system went down. The virus I got did several things, the one of which I expect is key here is rewriting the permissions in the data part of the system. (Tbird very competently distinguishes the code part (/thunderbird) from the data part (/.thunderbird) .) The malicious command had to have been in the nature of chmod -R 777, but that command "hit" the data side, not the program / code side. (What this thing did do to / in the operating system partition was multiply something so as to fill immediately that entire partition. That adversely affects logging in, of course, but there were no permissions changes in that partition.)

In this recovery effort, now six weeks along, part of what I've tried includes installing older Tbird code, from ver. 102 to 115.0 (or .1), expanding the targz files, copying / moving the code part into /opt (and, then, within /opt a separate directory for each version, e.g. /ver102, and running that version from the Terminal command line with the specific path to the profile, via -profile /full/path/to/profile. Tbird has no problem finding the profile; it just immediately shifts over into, "Wouldn't you like to create a new profile?" mode.

After finding no solution in that manner, I did set up a new profile under 115.3 (whatever is current at the moment). In that setting, I can presently import an older profile just fine. (I don't have those addresses anymore, starting at least three years ago, to indicate the time issue, here.) For this older profile, the Import progress indicator stays at 0% for the longest, and then the process is completed successfully.

(I noticed that the directory created is different from the directory used in the profile at issue, but it's the exact same (independent) email server. Also, the email server uses 995 for POP3 downloads, but Tbird wanted a certificate exception allowing use of 110. No, didn't "go there." More, on resetting the server specs for that new profile I'm not intending to use, at some later time.)

Here, using that exact same Import process for the profile that was used just fine with either 115.0 or 115.1, i.e., the current version as of mid-September (the time of the malware problem), the Import process jumps immediately to 25% and then quits very promptly with nothing imported.

I have invested close to two weeks now in systematically going through every /thunderbird directory and every /.thunderbird directory to remove all otherwise inexplicable permission settings of "x" for user, group, and other. In that relevant path, the directories are either u=rwx,g=,o=, (700) or u=rwx,g=rx,o=rx (755). Some of the .so libraries were showing "x", and I've changed all of those back to u=rw,g=rw,o= (660), and all other file types are either u=rw,g=,o= (600), or u=rw,g=rw,o= (660).

I've removed the lock (link), the xulstore.json, and the session.json files more times than I can now remember. I've left the .parentlock sometimes, and removed it also on other times.

There's got to be something "simple" remaining that I'm just overlooking.

What else can i provide in the way of information to help you in figuring out how we access that profile?

Thanks, greatly, in advance, for developing and maintaining TBird. I've been active with it since at least ver. 17, and that may have been an update to the prior version already in use. Always remember that linux systems don't get viruses. Announced as of about Sept. 19, there's a "new" one that intends to target linux systems. On Sept. 23, my main LM 21 (kernel version -86?) system went down. The virus I got did several things, the one of which I expect is key here is rewriting the permissions in the data part of the system. (Tbird very competently distinguishes the code part (/thunderbird) from the data part (/.thunderbird) .) The malicious command had to have been in the nature of chmod -R 777, but that command "hit" the data side, not the program / code side. (What this thing ''did'' do to / in the operating system partition was multiply something so as to fill immediately that entire partition. That adversely affects logging in, of course, but there were no permissions changes in that partition.) In this recovery effort, now six weeks along, part of what I've tried includes installing older Tbird code, from ver. 102 to 115.0 (or .1), expanding the targz files, copying / moving the code part into /opt (and, then, within /opt a separate directory for each version, e.g. /ver102, and running that version from the Terminal command line with the specific path to the profile, via -profile /full/path/to/profile. Tbird has no problem finding the profile; it just immediately shifts over into, "Wouldn't you like to create a new profile?" mode. After finding no solution in that manner, I did set up a new profile under 115.3 (whatever is current at the moment). In that setting, I can presently import an older profile just fine. (I don't have those addresses anymore, starting at least three years ago, to indicate the time issue, here.) For this older profile, the Import progress indicator stays at 0% for the longest, and then the process is completed successfully. (I noticed that the directory created is different from the directory used in the profile at issue, but it's the exact same (independent) email server. Also, the email server uses 995 for POP3 downloads, but Tbird wanted a certificate exception allowing use of 110. No, didn't "go there." More, on resetting the server specs for that new profile I'm not intending to use, at some later time.) Here, using that exact same Import process for the profile that was used just fine with either 115.0 or 115.1, i.e., the current version as of mid-September (the time of the malware problem), the Import process jumps immediately to 25% and then quits very promptly with nothing imported. I have invested close to two weeks now in systematically going through every /thunderbird directory and every /.thunderbird directory to remove all otherwise inexplicable permission settings of "x" for user, group, and other. In that relevant path, the directories are either u=rwx,g=,o=, (700) or u=rwx,g=rx,o=rx (755). Some of the .so libraries were showing "x", and I've changed all of those back to u=rw,g=rw,o= (660), and all other file types are either u=rw,g=,o= (600), or u=rw,g=rw,o= (660). I've removed the lock (link), the xulstore.json, and the session.json files more times than I can now remember. I've left the .parentlock sometimes, and removed it also on other times. There's got to be something "simple" remaining that I'm just overlooking. What else can i provide in the way of information to help you in figuring out how we access that profile?

所有回覆 (2)

more options

first install the latest version your distro has. Thunderbird in recent years has become increasingly pedantic about what version you were previously using the profile with and older profiles just do not have the information for the import for barf on. It it even thinks the current version is a different bit version or numerically version it will jack up and refuse the profile as "unsuitable" as it has been used on a higher version.

This can be overridden when using the profile by is using the --allow-downgrade command line parameter when starting Thunderbird. But I honestly have no idea what goes on inside the profile import.

BTW my preferred "move" approach is create a new profile in Thunderbird and upon it in file manager and copy the entire contents of the old folder into the new one, replacing anything new generally this "just works" Perhaps it may be a solution here, as you should only need access to the old folder.

more options

Thanks for having a minute. Your posts on all sorts of issues are very informative and helpful. You've obviously seen something like this before, because this one is certainly jacking up and not recognizing anything about the existing profile. Can't go backwards; can't go forwards.

In discussions with friends and colleagues around here, I'm learning that this profile rejection syndrome is arising with some noticeable frequency recently in the win10 and win7 contexts, as well.

The effort I made at something down this path is mentioned, but let me try that one more time for purposes of our thread, here. I'm also going to try the command line parameter suggested to see if any of the ver102 etc. efforts will recognize this profile with that bit of assistance.