Closed Bug 308162 Opened 19 years ago Closed 5 years ago

Multiuser Issue with Firefox 1.5 Beta 1 on a Terminal Server

Categories

(Toolkit :: Startup and Profile System, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 408513

People

(Reporter: wpinegar, Unassigned)

References

Details

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

The current profile system in Firefox 1.0.x and Firefox 1.5 Beta 1 has an issue
when running on multi-user systems such as Terminal Server or Citrix.  If I
logon with the samename user twice to the same Terminal Server and then attempt
to run Firefox 1.0.6 under both accounts the second account receives the error
message "Profile in Use", "Firefox cannot use the profile because it is in use.
Please choose another profile or create a new one."  Running Firefox 1.5 Beta 1
on the terminal server produces a slightly different error, "Firefox is already
running, but is not responding. To open a new window, you must first close the
existing Firefox process, or restart your system."

Firefox should correctly handle multiuser environments.  Also see bug # 308013.

Reproducible: Always

Steps to Reproduce:
1. Install Firefox 1.0.6 or Firefox 1.5 Beta 1 on a Windows Terminal Server.
2. Logon with the same user twice on the Terminal Server.
3. Attempt to run Firefox under both sessions.  

Actual Results:  
Received the error, "Profile In Use", on the second user account to startup Firefix.

Internet Explorer does not have this issue.

Expected Results:  
On multiuser systems the profile data should capable of being accessed by
multiple users.  If this is not possible then a working copy of the profile be
automatically stored in the sessions private %TEMP% subdirectory so multiple
instances of the same user can successfully run Firefox.
Known issue, this would either profile sharing (hopefully scheduled at the
moz1.9 timeframe) or cross-desktop runtime (which sounds like a lot of work).
Also as a note, mozilla at least allows the browser to start, you just have to pick or create a new profile. Firefox just displays this error and kills itself. It's a much larger problem than you can imagine on terminal servers, since it's impossible to use Firefox.
Whats the status of this bug?  It's still present in everything including Minefield (firefox) 3.0a on Windows 2003 Terminal Server (yes I even installed trunk software on a server to test this).  Will this be addressed at all? And if not, why not?
I need help,
the system is w2003_sp1 with MF4.0
we have installed firefox in version 1.5 
we have a rediretion of c:\anwendungsdaten\mozilla\firefox into a networkdrive.
so the user have after a reinstall of server also his profile.

the problem is:
the user starts on first server firefox.exe to browse in internet. This can be several times!
If the User starts from this server a Published Application from another Server with depends on firefox it give error to close the first session because it is open.
Reason on Network-Redirection-Folder in Profile of user is parent.lock open from first session.

any ideas to close this problem?

Thanks! 
This bug is a blocker for me. 

Using MS Windows 2003 server (italian, non-R2) this bug is still present, with Firefox 2.0.0.7 *AND* Thunderbird 2.0.0.7
Depends on: 408513
Attached image profiles.png
Firefox is capable of running on multiple instance but just need a new profile. (see Bug 408513)

(In reply to comment #6)
> I need help,


Best option:-
* train user to use profile manager
* uncheck Don't ask at startup (see profiles.png)

as an admin change this by going into each users "profiles.ini"
and in section [General]
set StartWithLastProfile=0




Dumb user option:-

I. create additional profiles default1, default2, ... default9
II. need to write a *.bat, *.js or *.vbs script with following logic
II.1.  Save commandline to saved_commandline
II.2   loop thru all profiles, default, default1, default2, ... default9
       try delete "parent.lock" 
       till successful.
II.3.  if not the "default" profile
II.4.     copy "default" profile to a new profile dir
II.5.     start firefox on new profile 
             (with commandline line as saved_commandline)
II.3b. else
II.4b.    start firefox on "default" profile also 
             (with command line as saved_commandline)


You may also want configure file name extensions *.html, *.htm, *.xhtml, *.xul etc and protocols http, https, ftp, ftps etc. to use your new script instead of firefox.exe


PS: also need to check whether when running firefox with the new script profiles.ini is not changed. I assume it should not.


Links
http://www.mozilla.org/support/firefox/profile
http://support.mozilla.com/kb/Profiles
http://the-edmeister.home.comcast.net/~the-edmeister/advice-html/simul-profiles_batch-file.html
http://www.borngeek.com/firefox/profile-tutorial/
http://kb.mozillazine.org/Browser_will_not_start_up
http://www.mattcutts.com/blog/how-to-fix-firefox-is-already-running-error/
http://humanreadable.nfshost.com/howtos/multibooting_firefox.htm

also study MOZ_NO_REMOTE env variable
http://the-edmeister.home.comcast.net/~the-edmeister/advice-html/simul-profiles_batch-file.html

there used to be an option like
c:\>   start firefox.exe -Profile "profile/"
http://forums.mozillazine.org/viewtopic.php?p=554965
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #8)
> also study MOZ_NO_REMOTE env variable
> http://the-edmeister.home.comcast.net/~the-edmeister/advice-html/simul-profiles_batch-file.html

alternatively 
c:\> firefox.exe -no-remote -p
As an update from commenting on this issue 6 months ago, we have ditched firefox on all our citrix servers because of this.

Profile sharing is absolutely not an option on servers that thousands of users login to. I can't even imagine what sort of security issue this would be for our users to possibly start up on profiles that are someone else's.

Automatic profile creation is absolutely not an option either in a global TEMP folder. I would think there are security issues here also.

Why is the profile not created in the user's temp folder? (ex c:/document and settings/user1/temp)? The global windows TEMP folder is for things like worker processes that span across an entire server system, not a browser profile.

Anyways, love firefox on our personal computers, but when we can't even start firefox, it's hat's off to IE.

Product: Firefox → Toolkit
This is still a problem in the era of firefox 3.6

200+ student users with the same login, same profile, logging in to run a single web site application. Creating loads of profiles is not an option. Nor is training 5 year olds on selecting profiles.

Would prefer the profile was just virtualised and appeared read only for each user.

There seems to be no useable workaround.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: