Closed Bug 926987 Opened 11 years ago Closed 6 years ago

Mac Ff Can't Use SMB --> Home profile.ini or Profiles/ folder

Categories

(Toolkit :: Storage, defect)

24 Branch
x86_64
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 502283

People

(Reporter: jamesisin, Unassigned)

References

Details

(Whiteboard: DUPEME?)

Attachments

(1 file)

User Agent: Opera/9.80 (Windows NT 6.1; Win64; x64) Presto/2.12.388 Version/12.16

Steps to reproduce:

Use Mac's AD integration.  Uncheck force local Home.  Include a home path in AD.

In our case users' home directories are at //server/users/username.  Once a user logs in, the usual ~/Libraries/Application Support/ folders/files are created.  When Ff is launched the expected ~/Libraries/Application Support/Firefox/ folders/files are created.


Actual results:

When you launch Ff, you are instead greeted with the Profile Manager.  It shows zero profiles (inspecting the folder reveals multiple profiles), and errors when any attempt is made to Create a profile.  In short there is no way around this dialog and Ff never starts.


Expected results:

Firefox should load the default profile without prompting and launch as per normal.
We are setting up several Mac's to NOT use local home directories. They will be using a smb://server/users/username share.  This share does contain the expected ~/Library/Application Support/Firefox/ folder. Said folder further contains the expected profile.ini file, Profiles folder (with maybe half a dozen profiles), and the Crash Reports folder.

Nonetheless, when I launch Firefox I am greeted with the Profile Manager which shows zero profiles. Opera (or Chrome or Safari) has no problem using this arrangement and its profile is carried from machine to machine as expected.  None of the Macs I've tried allow Firefox to launch from any of the non-local profiled users.

Seems to me that Firefox is using the wrong path for the user's home directory or is attempting to make certain changes as a different user.


Additional information:

If I hide the ~/Library/.../Firefox folder, when I then launch Firefox it recreates said folder with one (default) profile and no profile.ini file. (And I still get the Profile Manager at launch—with zero profiles.)

If I attempt to create a profile using the Profile Manager I get the attached permissions error.  This seems in conflict with the clearly permitted ability of Ff to create the aforementioned folders/files.

We have tested this with a variety of users and machines all with the exact same results.
OS: Windows 7 → Mac OS X
Hardware: x86 → x86_64
Seemt to be same bug with afp on network user. 
https://bugzilla.mozilla.org/show_bug.cgi?id=918612

revert Firefox to a old release resolved the issue for me.

Regards
Which release?
I don't think that other bug is related.  I tried using 23.0.1, 24, and 25.0b7 all with the same results: a new Firefox folder is created with both sub-folders and the profiles.ini file, but the Profile Manager is all I can get and it contains zero profiles (and cannot create one).
It is also interesting to note that each attempt to launch (any version of) Firefox creates a new profile folder under .../Profiles/.
James,
i think it's same bug. Somewhere Firefox have 2 process to the same file (sqlite)
Our environment is same (osx server with home directory) and client are bind to the server.
The only different think is our in AFP and you in SMB.
I have observed after update on client firefox from version 19 to 24 :
Firefox attempt to create profile and hang. No crash report.
Firefox attempt to create to  ~/Library/Application Support/Firefox/  with success and too to  ~/Library/Caches/... but fail here (i think).
I have resolved the hang issue with "Firefox 17.06 ESR", deleted all Firefox related file (profile).
We have 100 users.
if you see that http://www.mozilla.org/fr/firefox/organizations/faq/   Firefox 17.06 ESR   is Firefox 23
Sounds like a dupe of bug 918612.
Component: Untriaged → Storage
Product: Firefox → Toolkit
Whiteboard: DUPEME?
There are two reasons to suspect it is not exactly the same bug.

First, in our case Firefox never opens.  Always, we are greeted with the Profile Manager with no way to get past it.

Second, changing version of Firefox has no effect on the matter.  We have now tried 17.0.6esr, 23.0.1, 24, and 25.0b7 all with the same effect: the Profile Manager launches with zero displayed profiles (though any of those versions will re-create the /Firefox/ folder if it's absent or create a new profile folder thereunder).

If there is any testing we can do, please let me know.
I was able to get Firefox started by using a known-good profile folder and profile.ini file (taken from a different Mac using a local profile).  It took several minutes for Firefox to appear (several long minutes) and it runs like cold molasses, but I did get it started.  This was v24.  I will test the other versions I now have loaded and report again.
Ok.  I have now tested all currently installed versions.  Here is that report.

3.0.1 - Slow but works.  Does not load tabs (which may be expected).
17.0.6esr - Starts as expected (see note below).
19.0.1 - Starts as expected (see note below).
23.0.1 - Starts as expected (see note below).
24 - Starts with only a not-responding entry in the Force Quit dialog.  Eventually (ten minutes?) the window appears.  Eventually (another ten minutes?) the tabs appear (though they never load).  It moves into and out of the Not Responding state in Force Quit.
25.0b7 - Starts with only a not-responding entry in the Force Quit dialog.  Eventually (ten minutes?) the window appears.  Eventually (another ten minutes?) the tabs appear (though they never load).  It moves into and out of the Not Responding state in Force Quit.

Note: All versions (except 3, so 17, 19, 23, 24, and 25) offer the same error once they have the tabs up (if not loaded) appearing in a red band across the top of the tab: "The bookmarks and history system will not be functional because one of Firefox's files is in use by another application.  Some security software can cause this problem."

Profile corruption never occurs.  Hiding the /Firefox/ folder reverts to the same behavior as originally reported.  Thus it appears that my original post specifically relates to any new usage.  Employing a known-good takes us to the behavior as reported in the other bug report (918612).
James,
same here (with corrupt bookmark bar) : when i say "hang", firefox don't appear, but if you look in folder you can see the creation of profile.
When you delete profile folder when firefox run, you can see firefox menu appear but not useable.
Firefox appear after many minutes too.

Do this :
- delete all profile in  ~/Library/Application Support/Firefox/  and ~/Library/Caches/
- trash firefox ..do empty trash
- install a old version like ( 17.06 ESR : google old firefox mac ) 
- launch it .. don't import any bookmark or other from other navigator

And all is OK..this is my working procedure...let me know if it's ok for you.

PS : i have a custom redirection for all users caches folder : ~/Library/Caches/ are redirected via mcx to local machine /tmp/%users%/Library/Caches/***
PS2 : Please vote to bug 918612  and add you problem...this is not a AFP or SMB problem..this is a "process locked files" problem i think.

Regards
Your solution will not work.  As mentioned above, if I don't have a known-good profile in place I get the Profile Manager only.
James:

What you report in comment #11 (that FF 23.0.1 and below "work", but FF 24 doesn't) suggests that this bug is either a duplicate of bug 918612 or very closely related.  And if replicating your setup requires setting up Active Directory, it's unlikely that anyone in Mozilla will be able to do it.

So let's wait until we have a fix for bug 918612 (or a provisional fix).  Then you can test with a build that contains that fix, and let us know your results.
You should be able to use any LDAP server to emulate the matter.  In this case AD is merely providing the location for the non-local home directories.  In AD it is on the Profile tab under "Home folder" --> Connect --> [drive letter] --> "To:" --> [\\server\users\username].

It could be the case that problem X causes both of these behaviors.  It could also be that problem A causes the new profiles to be unavailable to Ff and to the PM while problem B prevents Ff from using certain functional profiles.  I'm not sure how to make that determination.

But, yes, that is the same bug report linked above and in either respect these seem at least intimately related.

I'm ready to test anytime.  Just need a build.
There's a test build available at bug 918612 comment #92.  Please test with it and let us know your results.
Exactly the same results as 23.0.1: with a known-good profiles.ini & /Profiles/ folder it works (still has that red warning about Bookmarks) and without that known good (no .../Firefox/ folder) only Profile Manager opens with zero profiles.
(In reply to comment #17)

Your comment is very unclear.  I originally understood you to be saying that the test build at bug 918612 comment #92 *does* fix your bug.  But now (in bug 918612 comment #101) you say it hasn't.

Note that FF 23.0.1 is *not* effected by bug 918612.  The first release that bug appeared in was FF 24.
Yes, 23 is not effected that other bug.  All versions are effected by this bug.  For all versions of Firefox with a non-local (smb shared) /home/ directory fail to launch but instead launch the Profile Manager with no available profiles.  This bug can be circumnavigated by using a known-good profile.  Once a known-good profile is used one can get Firefox to launch.  Then one can encounter the bug listed in 918612.
James,
i am not specialist of firefox but can you be more explicit :
What's append on the folders ? (application support/** and caches/**)
Are there caches redirected to local machine in AD like mcx (managed client redirector) in OD ?
You say "corrupt bookmarks".. but have you try without profile ?
You say "profile manager" ..but can you make a default profile and launch firefox ?

If your client as bind to a AD and on a Windows Server, is there a anti-virus who block creation of profile file ?

Sorry, i just investigate for find a solution.

Regards
Our NAS which houses the user share is running on an EMC VNX 5500 DataMover. The DataMover's OS is Dart (Unix), and it's running SMB for the share.  No anti-virus; no firewall.

The entire user's home directory is located in one location (the aforementioned share) and I am doing no redirection.

If you look at comment 11 you will see the exact quote for the bookmarks error and its context (I never said corrupt).

If you look at the original post you will see that the Profile Manager throws an error (attached above) when an attempt is made to use the Create button to create a profile.  Also, Ff DOES create the profile.  The problem appears to be that Ff doesn't (or can't) include that path in the profiles.ini file as it should.
Ok, so I formulated a different test.  I launched v24 and as per usual encountered the Profiles Manager, which I closed (Exit).  Ff as per usual created all the necessary files/folders as mentioned above.  I then went into the profiles.ini file using a text editor and created the missing [Profiles] section, pointing to the profile Ff just created.

BEFORE:

[General]
StartWithLastProfile=1



AFTER:

[General]
StartWithLastProfile=1

[Profile0]
Name=default
IsRelative=1
Path=Profiles/ou6a4csz.default


RESULTS:

No Profile Manager.  Ff was able to get past this bug (but of course v24 encountered the bug in 918612 after about a ten minute delay in opening, and it ran as a slug which seems normal for that bug).  Bored and annoyed waiting I force quit Ff v24.

So then I tried the same hack with the nightly (27.0a1).

RESULTS:

Bam!  Neither bug encountered.  Ff launched more or less as expected.  (Still has that bookmarks/history warning.)
I upgraded to Mavericks; no change in behavior.
Is there anything more I can do to help this bug report along?  I see the other bug is progressing nicely.
Here is one more possible clue.  The default profile is created as Firefox launches; however, the profiles.ini file is not created until AFTER the Profile Manager is Exited.
So... many versions have Firefox have passed since I first filed this bug report and the problem persists.  This means that when we roll this out users will be encouraged to use some other browser in our conference rooms (Opera, Chrome, and Safari have no issues as mentioned above).

It is still true that if I add a known-good profile/profiles.ini to an existing user's folder I can circumnavigate this bug, but currently Firefox (v31) is still not able to connect the profile it creates to the profiles.ini file.  (Launching Firefox results in the Profile Manager presenting zero profiles and unable to create one every time.  All of this behavior is outlined above.)

Does anyone want to take a crack at this bug?
I have confirmed this is still an issue in Firefox 38.0, Firefox 38.0.1, and Firefox 38.0.5, so this puts as with this bug in place for a few years.

Does anyone want to do anything related to this bug?
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: