Issue 42768 - Administrator privileges required for OOo installation
Summary: Administrator privileges required for OOo installation
Alias: None
Product: Installation
Classification: Application
Component: code (show other issues)
Version: 680m77
Hardware: PC Windows, all
: P3 Trivial with 34 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: oooqa
: 46143 53766 73600 91649 (view as issue list)
Depends on:
Reported: 2005-02-14 17:13 UTC by wiep
Modified: 2017-05-20 09:44 UTC (History)
6 users (show)

See Also:
Issue Type: FEATURE
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description wiep 2005-02-14 17:13:55 UTC
Best regards for everyone - my first post (issue) issued to OOorg.
I love this package - I use it since it had been StarOffice 5.0.
Now I have one complaint.

I think this is not a good idea to force users installing OOo to have admin

I work in a company (Philips in Europe) that has very strict requirements for
what is installed in our computers. OOo is not in their "accepted software list". 

It means that I had to install it without asking anyone. I have "Power user's"
rights. Up to 1.1.4 it worked - I could use OOo.

Please make some statement - if the non-administrator installation is something
that you really plan to withdraw from, or it may come back?

I think there are many more people in this situation.

Way to reproduce:
try to install without administrator priviledge.
Comment 1 wiep 2005-02-14 17:42:43 UTC
should be: 
installation for one user only (even if it is connected with limited components
registration etc... - rarely used, but for which administrator is needed)
Comment 2 Olaf Felka 2005-02-14 18:16:57 UTC
Comment 3 Olaf Felka 2005-02-14 18:22:34 UTC
Comment 4 etnoy 2005-02-21 12:09:07 UTC
I am hooked up on a non-admin account on my school and the OOo 1.1.4 and 1.1.0
installs work just fine. Now I wanted to test the 1.9 beta versions, downloaded
75 MB of data just to get the message that I must be administrator to install
the software. 
I really dislike this kind of behaviour and just locking out the user. At most,
it could display a very visible warning that says that some features won't work
unless installed by an admin, then it's up to the user to continue.

I see this as quite important for OOo, and would like someone to close this bug
Comment 5 Olaf Felka 2005-03-07 09:08:33 UTC
This is not a bug! OOo 2.x needs admin rights to install. Works as designed.
AFAICS this won't be changed in the near future.
Comment 6 wiep 2005-03-09 11:49:12 UTC
If it is not planned to be changed, please provide non admin users a special
installer - to make a single desktop installation possible. 

I hate idea of being forced to recompile everything only to install the software
on my desk at work!

I think administrator priviledges are required only for "install for all users"

It is not fair, because in other OS you needn't be administrator - you can
install it always in your own /home/xxx/directory.
Comment 7 etnoy 2005-03-10 11:01:16 UTC
I agree with the above poster, an option to force installation no matter what is
needed. Tell me, what breaks when you install as non-admin? Could the installer
generate a big fat warning?
Comment 8 dilberg 2005-09-21 16:24:18 UTC
*** Issue 42768 has been confirmed by votes. ***
Comment 9 soloturn 2005-09-25 17:51:19 UTC
the issue is that administrator priviliges are required, and it should not be
the case. any user should be able to install it.
Comment 10 jdeisenberg 2005-09-25 18:25:54 UTC
I am curious as to the comment on 7 March: "This is not a bug! OOo 2.x needs
admin rights to install."  The word "needs" is key here. Some specifics of what
things would not be possible with a normal user install would help us understand
the issue better.

This issue really is an obstacle for evangelizing OOo. You want to be able to
hand someone a disc and say, "Use OOo for a while; you'll love it." You don't
want to have to ask, "Oh, by the way, do you have adminstrator privileges on
your machine?"

If requiring admin privileges is a matter of single user vs. all users install,
then put that question as close to the beginning of the install process as
possible. (Otherwise, you have the possibility of people getting 90% of the way
through the install and then finding out they need to be admins--a sure way to
alienate potential customers.)

Comment 11 etnoy 2005-09-26 12:43:13 UTC
Yes, this "bug" as I call it can give serious problems later on. About a year
ago was a problem with OSS software and admin-requirements on win32, and when I
saw OOo take this turn too I felt very disappointed. Admin requirements are
never good, and it must be some way to at least try instead of the "nope, I
don't want to continue because.." attitude the current installer has.
Also, there should be an option to install either systemwide or only for the
current user.
Comment 12 reckdahl 2005-09-29 16:27:27 UTC
The "This is not a bug!" comment was made because "of" 
mistakenly thought that  
Comment 13 reckdahl 2005-09-29 16:53:27 UTC
The "This is not a bug!" comment was made because "of" user 
mistakenly thought that the spec did not require the 
installation to provide non-admin installation.  Look 
at the Windows Installer GUI Spec on 
In Section 6.8 it describes supporting admin and non-admin 
installation, for example saying that if a non-admin tries 
to perform an all-users installation then the installation 
program should only support the single-users installation. 
So from the spec point of view, this is clearly a bug. 
It is also a "bug" from a product-design point of view. 
Windows does not permit non-administrators to install 
fonts, but otherwise the rest of OpenOffice does nothing 
for which Windows requires admin privileges.   
This means that the installation program could have (and  
should have) been written to check admin rights and then  
install everything but the fonts for non-administrators. 
Comment 14 lohmaier 2005-11-20 22:48:02 UTC
*** Issue 53766 has been marked as a duplicate of this issue. ***
Comment 15 lohmaier 2005-11-20 22:50:13 UTC
*** Issue 46143 has been marked as a duplicate of this issue. ***
Comment 16 etnoy 2005-11-21 20:34:45 UTC
I repeat, this is a bug and it should be fixed.
Comment 17 gaufille 2006-01-18 14:54:54 UTC
I do not know if it is a bug, but it is really not a nice feature in my case :-(

This is the same situation for unixes (solaris and linux in my case). In our
software development department (about 300 peoples), all our software tools are
installed in a specific networked shared home (/home/tools) and are owned by a
specific user (toolsmgr). With the native installers of 2.0, it
is nearly impossible to install it in this conditions. The
script (downloaded from the developpers resources) allowed me to succeed on this
platform, but I can not install 2.0 on our Linux RedHat EL4
machines because rpm can not be executed in install mode without root privileges...

Currently, the only option I see to keep our tools homogeneous for every
platforms is to keep 1.1...

You should probably not define or limit the deployment model of
in place of the users : some are using it on their own box, others rely on an
external administrator, others split up the administrative responsabilities
between teams, etc. It is probably better to let people like BlastWave, Ubuntu,
Debian, RedHat, etc. doing this packaging job : it is their reason to be.

Comment 18 lsuarezpotts 2006-06-16 16:40:19 UTC
Martin: this is causing rather a lot of grief. Would you be able to tell us the status of this?

Comment 19 Olaf Felka 2006-06-19 08:31:38 UTC
No changes about this yet.
Comment 20 Olaf Felka 2007-01-18 11:17:00 UTC
*** Issue 73600 has been marked as a duplicate of this issue. ***
Comment 21 twinsun 2007-01-18 13:11:58 UTC
Someone told me : "Use setup with parameter /a.
You'll get an installation without admin priviliges but without
systemintegration". Didn't tried it yet.

It would be better to have a combobox or a checkbox when the installation start
to let the user choose.
Comment 22 schuliebug 2007-10-31 08:49:47 UTC
If admin rights are needed to install parts of OO, this should be done using
elevated priviliges. That way also non-admin users can install OO.
Comment 23 thurnerrupert 2008-01-20 20:27:03 UTC
setup /a means "administrative install", but unfortunately it checks the same 
privileges - and i guess this one is a real bug.

but in general, it would be very nice if installing openoffice works like all 
the other medium decent installers which let you choose between "install for 
all users" (which needs sometimes admin privileges), and "install for this 
users" (which never needs admin privileges).

Comment 24 Olaf Felka 2008-07-15 12:40:54 UTC
*** Issue 91649 has been marked as a duplicate of this issue. ***
Comment 25 bib_bxl 2009-07-23 00:17:20 UTC

people would like probably to try ooo in my organisation, but the motived people
would like to show a bit that it works, before starting asking autorization to
the Administration services. The potential are about 10.000 users...

For this reason, this would be crucial to be able to install ooo as simple user,
as we do on our machines with many other programs. 

Could it here be possible, in simple words for managers that are still
IT-iliterate, to have the list of the reasons for which an admin access is
necessary? And how to install it without? Thanks in advance for your help. 

Comment 26 jdeisenberg 2009-07-23 02:26:20 UTC
bib_bxl: I have gotten around the problem by using portable; you
don't need to be admin to install it (at least I didn't the last time I tried),
and you can install it to hard disk just as well as to a flash drive.
Comment 27 bib_bxl 2009-07-24 11:11:16 UTC
Thanks jdeisenberg: this worked. This is a solution that should be mentioned,
specially for corporate targets. 

I hope anyway that there will be an answer on the very question we formulated
from the persons that have a competence to do it, so we can go on with this issue. 

All the best. 
Comment 28 bib_bxl 2009-07-24 17:11:23 UTC
Thanks jdeisenberg: this worked. This is a solution that should be mentioned,
specially for corporate targets. 

I hope anyway that there will be an answer on the very question we formulated
from the persons that have a competence to do it, so we can go on with this issue. 

All the best. 
Comment 29 Rainer Bielefeld 2014-01-07 09:23:21 UTC
Not a bug, works as designed, workaround for not-admin-users exists, so NOT_AN_ISSUE.