I have a administrator privileges in Ubuntu 12.10 but when I try to install some applications Ubuntu requiere authentication, I write my password, but doesn't work
somebody could help me?
I have a administrator privileges in Ubuntu 12.10 but when I try to install some applications Ubuntu requiere authentication, I write my password, but doesn't work
somebody could help me?
There are a few things to try.
If you're entering numbers from a numeric keypad, make sure Number Lock is on and that MouseKeys is not on unless you want it to be.
This is typically only an issue for people who switch frequently between different language settings. If you've not deliberately changed your keyboard layout since installation, this is very unlikely to apply to you.
But there is a related problem that can apply:
...then it is possible that some bug could cause the password not to be received and verified correctly.
If you can change your keyboard layout and still enter the password, try that. Otherwise, see below.
There are multiple causes of the problem that can sometimes be solved by doing this.
When you reset your password, make sure it is at least one character long. (Of course, for security, it should be much longer. But blank/empty passwords sometimes trigger bugs. So it's especially important, for the purposes of troubleshooting this problem, that it not be totally blank. Of course, it's still best if it's a good, strong password.)
In case of a bug relating to the interpretation of non-English symbols, you might try a password containing just Latin ("English") characters, numbers, and/or common internationally used punctuation symbols.
There is an easier way to change your password that is not generally applicable but may work in your particular situation. The Software Center authenticates graphically with PolicyKit. You can try changing your password non-graphically from the command-line. If you want to try this, press Ctrl+Alt+T to open a Terminal window. Then run:
passwd
That will let you try to change your password. You'll have to type the old password, then the new password twice. In the Terminal, you won't see any placeholder characters like *
when you enter a password. It will look like nothing is happening. That's normal; just type each password in and press enter.
If that fails, or if it appears to succeed but you still cannot authenticate successfully in the Software Center, you can try:
sudo passwd $USER
Make sure to include $USER
. Don't replace it with anything, just type it as is. It automatically represents your username. (This differs from the above command in that this attempts to authenticate you as root and then change your password as root. Sometimes that succeeds where other methods fail. Sometimes.)
If neither of those works, you'll have to try changing your password in one of those ways. If you want, you can just skip to that.
If you are unable to complete any of those techniques for changing your password, or get error messages, try this way. (If you are able to change your password successfully but the Software Center still won't authenticate you, then that method is unlikely to produce any better results, though.)
To see, try running this command in the Terminal (Ctrl+Alt+T):
sudo echo success
You'll have to enter your password (don't worry that nothing appears on the screen as you type it in) and press Enter.
If that command outputs success
in the Terminal, then you were able to run a command as root with sudo
. You should then add that information to your answer, and also let us know what flavor of Ubuntu you are running (regular Ubuntu, Kubuntu, Xubuntu, Lubuntu, etc.). You should also provide us with the output of these commands:
ps aux | grep [p]olkit
pkcheck --action-id org.freedesktop.systemtoolsbackends.set --allow-user-interaction --process $(pidof -s bash)
And please also describe what, if anything, happens when you run that second command, besides text appearing on the terminal. It might be nothing, but typically you'll get a graphical authentication dialog followed by text output.
That second command tests if PolicyKit is working for authentication. (Milan Bouchet-Valat deserves credit for the general form of that command; see the comments in this bug.)
Other people with a similar problem who are reading this can create a new question and include these results (or add these results to your question, if you have already created one for the problem).
sudo
and gksu
/gksudo
as a workaround.If sudo echo success
worked (see above), then regardless of the output of the subsequent commands, this means sudo
is working.
sudo
cannot replace PolicyKit entirely, in the context of the way Ubuntu software works. But it can replace it mostly, because many programs that use PolicyKit to perform administrative tasks will also work when run with sudo
.
For graphical programs, you should use gksudo
and not plain sudo
. Try:
gksudo software-center
If you don't have gksudo
, then you can install it. It is provided by the gksu
package. You can't install it in the Software Center if the Software Center is not working, but you can install it on the command-line:
sudo apt-get update && sudo apt-get install gksu
You can install other software that way too, as a workaround to being able to use the Software Center.
If you don't want to install gksudo
or it doesn't work, you can safely use sudo -H
or sudo -i
to attempt to run graphical applications as root:
sudo -H software-center
sudo -i software-center
If sudo apt-get ...
works for installing software but you are unable to get the Software Center to work by running it with gksudo
, sudo -H
, or sudo -i
, then you can install another graphical package browsing and installation/deinstallation program: Synaptic.
sudo apt-get update # you can omit this if you've run it very recently
sudo apt-get install synaptic
Some of my recent experiences troubleshooting Software Center problems suggest to me that Synaptic may run successfully as root even in situations where the Software Center is unable to do so. This is really just a guess; I could be mistaken. If you cannot run the Software Center, it's worth a try.
gksudo synaptic
sudo -H synaptic
sudo -i synaptic
sudo
doesn't work, maybe you're not an administrator.If you were able to run sudo echo success
and have success
printed in the console below where you entered the command, then you are an administrator. (Either that, or you have special privileges to run the echo
command as root, which is very unlikely.)
But if that failed, the most likely (though not only) cause is that you aren't really an administrator. Sometimes users accidentally remove their own administrative powers. And there could potentially be bugs that would cause this (maybe...).
To check if you are an administrator, run:
groups
You're running Ubuntu 12.10. In Ubuntu 12.04 and later (including 12.10), administrators are members of the sudo
group. So, see if sudo
is listed in the output of groups
.
If it is not listed, then use one of these techniques to add yourself back as an administrator.
If sudo
is listed, then there may some misconfiguration preventing members of the sudo
group from being recognized as administrators. In that case, enter recovery mode and examine the contents of the file /etc/sudoers
.
If you cannot enter recovery mode, then you can perform the first 7 steps of this procedure (ending with sudo mount /dev/sda1 /mnt
, replacing /dev/sda1
with the root partition of your installed Ubuntu system, which that procedure explains how to find).
Then examine the file /mnt/etc/sudoers
. (You can do this from the graphical file browser in the live system, or with the command cat /mnt/etc/sudoers
.)
The file should contain:
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
In particular, there should not be a #
symbol at the beginning of the line that starts with %sudo
. (That would make it a comment, i.e., ignored by Ubuntu.)
If it's missing or starts with #
, you can fix it by editing the file by running:
visudo
You should not edit the file without visudo
, because visudo
keeps you from messing it up in severe ways and causing more problems. (You can still create a bad configuration, but it keeps you from creating an ambiguous or meaningless one by checking for good syntax.)
In recovery mode, you'll often have to run this first to enable you to make changes to the system:
mount -o remount,rw /
So either run that before visudo
, or if you run visudo
and it's unable to save changes, then run that mount
command and try visudo
again.
If you're doing this from a live CD/DVD/USB, don't run plain visudo
, because that will not do what you want. That would edit the configuration of the live system. Also, unlike in recovery mode, on a live CD you have to use sudo
to run commands as root. So instead, run:
sudo visudo -f /mnt/etc/sudoers
On a live CD, if you followed step 7 there correctly, you should not need to run any further mount
command (and if you did run that mount -o remount
command, it would not do what you wanted, because it would try to remount the live environment's filesystem rather than the installed OS's filesystem).
sudoers
file is misconfigured in a less common way.If you're in the sudo
group and the %sudo ALL=(ALL:ALL) ALL
line was present and uncommented in your sudoers
file (see above), then it's still possible some misconfiguration in that file could be causing the problem.
For example, an exception (that partially or fully undoes the %sudo
line) could be present afterwards.
So if you are in the sudo
group but sudo echo success
does not work when run while booted normally into the installed system (i.e., not a live CD/DVD/USB, and not recovery mode), please provide us with the complete and exact contents of the /etc/sudoers
file.
You can add that to your question.
For others experiencing similar problems, you can add that to your own question.