Bug 41670 - Star Office 5.2 can't be used with homes mounted via NFS
Summary: Star Office 5.2 can't be used with homes mounted via NFS
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-05-21 19:15 UTC by Need Real Name
Modified: 2007-04-18 16:33 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2003-06-06 12:50:40 UTC

Attachments (Terms of Use)

Description Need Real Name 2001-05-21 19:15:38 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686)

Description of problem:
Star Office is installed on a local hard disk with the /net option. The
user's home directories get mounted from a HP-UX server via NFS. Things
worked perfectly with our RedHat 6.2 machines. But since we introduced
RedHat 7.1 on some of our machines Star Office won't work on those
machines. The error messages differ depending on whether the user has used
Star Office before.

How reproducible:

Steps to Reproduce:
a) User that has not previously used Star Office:
1. Run soffice. "User" part of the installation will run as expected.
2. Run soffice again.

b) User who has previously used Star Office on RH 6.2 (meaning that the
configuration files are already in place in his home directory):
1. Run soffice. Star Office will work as expected.
2. Close Star Office.
3. Run soffice again. 

Actual Results:  
a) Star Office will abort loading with the message "failed to load
necessary component".

b)An error message "Error loading document
macro://#initialize.Explorer.Main() BASIC >runtime error Object variable
not set" will appear. After clicking "Ok" Star Office is started but the
icons on the Star Office desktop are missing and the file open/save dialogs
don't contain any files or directories so working with Star Office is not

Expected Results:  Star Office should have started up normally and show the
Star Office desktop.

Additional info:

If a user with the "corrupted" configuration files from RH 7.1 goes back to
RH 6.2 Star Office will have the same error messages. The only thing that
helps is deleting the configuration files and doing the user part of the
installation again on RH 6.2.

Comment 1 Rex Dieter 2001-07-05 20:06:35 UTC
We're using StarOffice 5.2 on NFS mounted home directories (both RH6.2 and RH 
7.1) just fine.  I've patched StarOffice with updates available from sun... 
maybe that will help you too.

Comment 2 Andreas J. Bathe 2001-07-05 22:13:02 UTC
I can confirm this bug: all old rh 6.2 workstations have only some little
problems, but RedHat 7.1 with all updates and several kernels from the 2.4 tree
can't use StarOffice 5.2 anymore. When I softlink .user52.rdb and the
so2-directory to a local disk area, everything runs well.

Because the dmfe driver isn't included in the standard rh kernel I always have
to recompile the kernel by myself. I even tried the new 2.4.6 and discovered an
horrible nondeterministic bug: I copied two files to to an 6.2 NFS-server, two
7.1 clients with 2.4.6 kernel couldn't see the files with ls - although I could
get them with cat !!!

One Debian system and older rh-versions hadn't  a problem to ls these two files.
What's going on here? People at my company don't like rh-versions greater than
6.2 because things go worse than better.

Where is the solution of the StarOffice problem? It has something to do with NFS
and the new kernel, I can definetely confirm that.

Comment 3 Andreas J. Bathe 2001-07-06 03:35:34 UTC
I found a workaround: Install StarOffice 5.2 remote on a RH 6.2 system with your
home NFS-mounted to this remote host, then use StarOffice on the local host with
2.4.x-kernel. This explains the comment above.

Comment 4 Need Real Name 2001-07-06 10:55:22 UTC
Well, the previous workaround will work fine unless the user decides to do
something in Preferences. Then Star Office will try to write to the
configuration file(s) and corrupt them and we have the same problem again. The
only working workaround I see at the moment is a wrapper script that does the

- check if configuration files exist in the user's home (meaning Star Office has
already been started and installed), if not, give the user default configuration
files created by a local "dummy" user

- copy the configuration files to a directory in /tmptmp (or any other local,
non-NFS partition)

- set $HOME to this directory

- start Star Office

- when Star Office has finished, copy the configuration back to the user's home
and reset $HOME

Comment 5 Dennis Brylow 2001-10-26 21:13:15 UTC
Seems to have gone away with the 2.4.9 kernel upgrade.
This may be a duplicate of bugid #52652.

Note You need to log in before you can comment on or make changes to this bug.