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: Always 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 possible. 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.
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. http://supportforum.sun.com/staroffice/patches.html
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.
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.
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 following: - 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
Seems to have gone away with the 2.4.9 kernel upgrade. This may be a duplicate of bugid #52652.