Closed Bug 90682 Opened 23 years ago Closed 21 years ago

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

Categories

(Core Graveyard :: Profile: BackEnd, defect)

Product:
Core Graveyard
Component:
Profile: BackEnd
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
Future

People

(Reporter: benc, Assigned: ccarlen)

References

Details

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.
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
-> future
Status: NEW → ASSIGNED
Target Milestone: --- → Future
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).
read-only nfs mount, or rw?

What operating system does this occur on?  (Currently set to PC/other.)
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.
All/all. This bug is possibly related to bug 162025.
OS: other → All
Hardware: PC → All
See also bug 19163.
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
*** Bug 204643 has been marked as a duplicate of this bug. ***
Summary: [NFS] Profile on remote (networked) disk: supported/unsupported → [NFS] Profile on remote (networked) disk: supported/unsupported (home dir)
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-
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
Closed: 21 years ago
Resolution: --- → DUPLICATE
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.


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 → ---
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
> Not the right duplicate.

At the time I did that, it was. Read comment 13. Comment 14 then changed it to
something else.
> 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?
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?
That's good news. Can we get some verification?
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → WORKSFORME
I'll verify this if I can get my Solaris NFS configuration working.
Keywords: verifyme
QA Contact: ktrina → benc
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) 
 
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.
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.