[NFS] Profile on remote (networked) disk: supported/unsupported (home dir)

VERIFIED WORKSFORME

Status

Core Graveyard
Profile: BackEnd
VERIFIED WORKSFORME
17 years ago
2 years ago

People

(Reporter: benc, Assigned: Conrad Carlen (not reading bugmail))

Tracking

Trunk
Future
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
Could not find an existing bug report.

I vaguely recall that this might not have been supported for NFS volumes mounted
in UNIX. Either that, or it was running tha binary from NFS, or running the
browser and sending the display someplace else.

Anyhow, it underlies bug 89903.
(Reporter)

Updated

17 years ago
Summary: Profile on remote (networked) disk: supported/unsupported → [NFS] Profile on remote (networked) disk: supported/unsupported
Sending to back end. 
Assignee: ben → ccarlen
Component: Profile Manager FrontEnd → Profile Manager BackEnd
QA Contact: gbush → ktrina
(Assignee)

Comment 2

17 years ago
-> future
Status: NEW → ASSIGNED
Target Milestone: --- → Future

Comment 3

15 years ago
If the profile is on an nfs remote share, Chimera 0.6 won't start up (it will crash when 
loading). See bug #179035 for more details (including a stack trace).
(Reporter)

Comment 4

15 years ago
read-only nfs mount, or rw?

Comment 5

15 years ago
What operating system does this occur on?  (Currently set to PC/other.)

Comment 6

15 years ago
This bug makes it impossible to launch Mozilla from an account whose home directory is on an 
NFS volume, as there is no way around the failure in the profile manager. This is running Mac OS X 
10.2.6, as a Netinfo user with a home directory on an NFS volume

I get "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) 
[nslProfileInternal.currentProfile]".

This problem does not occur with either Netscape 7 or Camino.

Comment 7

15 years ago
All/all. This bug is possibly related to bug 162025.
OS: other → All
Hardware: PC → All

Comment 8

15 years ago
See also bug 19163.

Comment 9

15 years ago
Uh, PC/Linux. If you're looking for the problem on the Mac platform, that's
separate. It's bug 196487.
OS: All → Linux
Hardware: All → PC

Comment 10

15 years ago
*** Bug 204643 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Summary: [NFS] Profile on remote (networked) disk: supported/unsupported → [NFS] Profile on remote (networked) disk: supported/unsupported (home dir)

Comment 11

15 years ago
As I said in 204643, this seems like it would be a biggie for corporate software
adoption (I know it is in my little environment).  Please review and consider
changing milestone from future.
Flags: blocking1.4?
Please re-verify this bug, and post exact setup and mozilla/OS version.  Also,
how the NFS volume is mounted (and what OS that is running).

This was fixed in bug 76431.  If this is verified, it would be a regression.  I
think this is actually working correctly, and this report is confused.

Does not block 1.4 unless someone verifies this is a regression.

The Mac OS/X bug is something different (as per comment above).
Flags: blocking1.4? → blocking1.4-
(Assignee)

Comment 13

15 years ago
It can't be a regression from anything fixed by bug 76431. Notice when this was
originally reported. 76431 wasn't checked in until 2002-05-15. The original
report is too vague in addition to being old, and the other 2 reports from which
we can tell the OS are both OS X. That is bug 196487.

*** This bug has been marked as a duplicate of 196487 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Comment 14

15 years ago
This is definitely still occurring for me.  I'm running:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401

on kernel 2.4.18-24.7.x

on a RedHat 7.3 installation.  The NFS server is Solaris/SPARC running 5.8
(uname -r returns 5.8).  When I first had the problem, I was running ClearCase,
along with their oddball mvfs/automount stuff.  I've since removed that and
still have the problem - on launch, it spins for a few seconds, completely
locking down XWindows for a minute or two.

It's definitely possible that the bug isn't an NFS issue, and I'm
misinterpreting what's happening, but I can launch on every single try if I'm a
"local" user (home directory on local volume, and user defined in local
/etc/passwd as opposed to NIS).  I've tried as two different "remote" users
(home directory on NFS mount, user defined via NIS), and had the same results.  

Let me know if there's more info I can provide.

Comment 15

15 years ago
Not the right duplicate.

Maybe this problem occurs if the NFS connection is temporarily lost. Does
application software like Mozilla have to do something to keep the connection
active or to open it?
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 16

15 years ago
It also might be worth noting that the most recent version I've found that
DOESN'T seem to have this problem is:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
(Assignee)

Comment 17

15 years ago
> Not the right duplicate.

At the time I did that, it was. Read comment 13. Comment 14 then changed it to
something else.

Comment 18

15 years ago
> Does not block 1.4 unless someone verifies this is a regression.

I'm re-requesting blocking1.4, not to be an annoying pest, but to make sure that
you realize that this does appear (at least to me) to be a regression.  Feel
free to re-deny :).

If you'd like me to test other versions (between 1.0.1 and 1.4a) to target the
regression point, let me know.
Flags: blocking1.4- → blocking1.4?

Comment 19

15 years ago
Just downloaded and installed 1.4b.  This problem doesn't appear to be present
here (and just to make sure I'm not crazy, I tried 1.4a again, and it's still
there....removed and reinstalled 1.4a, and it's still there).  However; I'm
entering this comment from 1.4b running under an account whose home directory is
an NFS mount, and all seems to be well.

I've removed the 1.4 block request, as far as I'm concerned, you can close the
ticket.
Flags: blocking1.4?
(Assignee)

Comment 20

15 years ago
That's good news. Can we get some verification?
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 21

14 years ago
I'll verify this if I can get my Solaris NFS configuration working.
Keywords: verifyme
QA Contact: ktrina → benc

Comment 22

14 years ago
I'm afraid this bug is still present (tested with Mozilla 1.6). 
I was able to reproduce it on a SuSE Linux Enterprise Server 8, logged on as a 
user defined on a SuSE 9.1 box (running NIS and hosting the home directories). 
On the 1st host the resource host2:/home was mounted via NFS as /home. 
 
This is basically what happened: 
 
(logged on as user "user", $HOME was /home/user (NFS!) ) 
   cd /usr/local/mozilla 
   rm -Rf ${HOME}/.mozilla 
   ./mozilla 
(The Mozilla Profile Manager warned me that the "default" profile "was in 
use", the same happend when creating a new profile and trying to use that one. 
Mozilla wouldn't start.) 
 
(Right after that, I tried the following) 
   cp -R /home/user /tmp 
   HOME=/tmp/user && export HOME 
   rm -Rf ${HOME}/.mozilla 
   ./mozilla                                                                    
(Mozilla started normally) 
 

Comment 23

14 years ago
I'm not sure whether this really is a bug in Mozilla. This might have to do with
the "lock file", which in fact is a symbolic link. When trying to create
symbolic links on NFS-mounted file systems I got an error, even though the link
seemed to have been created correctly. The server was a SuSE9.1 box, on a SLES8
client I got an "unknown error 524", whereas on a FreeBSD5.2 client the error
returned was "10004". I wonder if it may be the error code returned after
creating the symbolic link that confuses Mozilla.
(Reporter)

Comment 24

11 years ago
V/fixed.

(Thinking about this...) in a previous job, I used nfs/based home directories to run firefox and mozilla all the time.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.