Apache OpenOffice (AOO) Bugzilla – Issue 17517
OpenOffice + NFS instalation
Last modified: 2003-10-09 14:23:26 UTC
I used to install OpenOffice in to NFS exported directory, in such way that all desktops could run it. The home directory is also exported to all desktops via NFS. This uesed to work up to version 1.0.3. Since I installed the 1.1RC (and 1.1RC2), this strategy no longer works. In the "server" machine, OO is properly installed and runs smoothly, but in the "client" machines every time a user tries to run OO (s)he get the message: The application cannot be started. The component manager is not available. Start the setup application to repair the instalation from the CR or the folder containing the installation packages. The OO was installed in the usual directory /usr/local, which is exported via NFS to all machines in my network. Is there something in the installation and/or in the configuration files that is specific to the machine and can not be shared with others? Thanks.
A detailed step-by-step walkthrough of your installation would be helpfull.
Created attachment 8108 [details] Setup Guide
The OO 1.1RC2 was installed from official tar.gz file. I unpack it and ran the install scritp with no command line parameters. It was correctly installed in the default directory /usr/local/OpenOffice1.1RC. The whole /usr/local/ directory of that "server" machine is exported, via NFS, to all others "client" machines. In each client, the mounting point for the /usr/local is /usr/local as well. Therefore, the user can run OO from any client machine as it was installed locally installed in /usr/local. This strategy to share one installation of OpenOffice through the whole network used to work up to 1.0.3.
Any idea?
Unfortunately none...
To me this setup looks absolutely ok. Maybe we have a problem with the system libraries (wild guess). biloti, could you please try to do a full install and run the office on the client machine? If this works, we can exclude problems with the system itself. We need following additional information to reproduce the issue: 1. Server-OS 2. Client-OS 3. The permissions for the exported directories
Server-OS: Debian/GNU Linux, woody (3.0r1), glibc 2.2.5 Client-OS: (the same) The file /etc/exports in the server is: /usr/local 200.17.211.85(rw) That is, the client can read and write in /usr/local where the OO is installed. The file /etc/fstab in the client contains: server:/usr/local /usr/local nfs defaults 0 0 Anything else?
Hi all, I've done some experiments on NFS and the problem seems connected with the lock options. Infact by setting STAR_PROFILE_LOCKING_DISABLED=1 export STAR_PROFILE_LOCKING_DISABLED # # SAL_ENABLE_FILE_LOCKING=1 # export SAL_ENABLE_FILE_LOCKING # into program/soffice all seems to work. Another way is to mount nfs area with -o nolock option. This is a real problem.... Davide
Hi I tried the Davide's sugestion and it doesn't work for me. I still get the same error when trying to run OOo from the NFS clients. I have just installed the 1.1RC3 and problem is still there. Biloti.
Look at Issue 18844. It describes the same Problem , when OO will be installed on a Client with NFS mounted devices. In my way I' installed OO on an server (/usr/local), all clients in my network mount /usr/local with NFS. Up to OO1.0.3 eyerythink works well, with OO1.1rc3 I got th e following error message on the clients. On the server everything is o.k.: The application cannot be started. The component manager is not available. Start the setup application to repair the instalation from the CR or the folder containing the installation packages. repairing fails! After a few test, I tried to install OO1.1RC3 on the NFS Client and I got the following error message: Registering the components 'The libctl645li.so' component was unable to be registered retry does nothing (keeps failing) ignore goes to next file, and that fails alse (implreg.uno.so) cancel just goes to next file (which fails) On the Server an the Clients I use Slackware Linux with Kernel 2.4.21 and glibc 2.3.1.
This depends on the Suse 8.2 srcipts. Start the nfs and nfslock deamons in yast2. *** This issue has been marked as a duplicate of 19339 ***
Dupe.
Just as a comment, I noticed this problem on a Debian Wood (3.0r1) linux box.
Ops! Debian woody. Sorry :)
The problem was resolved when I started to use the nfs-kernel Debian package instead of nfs-user Debian package.