nm-applet fails when another user is logged in

Bug #284596 reported by Stepan Zastupov on 2008-10-16
This bug affects 105 people
Affects Status Importance Assigned to Milestone
Linux Mint
Fix Released
Fix Released
network-manager (Fedora)
Fix Released
network-manager (Ubuntu)
Declined for Jaunty by Sebastien Bacher
Declined for Karmic by Sebastien Bacher
Declined for Lucid by Sebastien Bacher
Declined for Maverick by Sebastien Bacher

Bug Description

Binary package hint: network-manager

nm-applet failed to acquire NetworkManagerUserSettings service when another user is login:
~ % nm-applet

** (nm-applet:11596): WARNING **: <WARN> applet_dbus_manager_start_service(): Could not acquire the NetworkManagerUserSettings service as it is already taken. Return: 3

(nm-applet:11596): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

How to reproduce:
Update to intrepid
Log on first user
Switch to second and he would not be able to use nm-applet.
network-manager and network-manager-gnome version: 0.7~~svn20081015t024626-0ubuntu1

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/2008071615 Fedora/3.0.1-1.fc9 Firefox/3.0.1

Description of problem:
When multiple users are logged in, the NetworkManager applet will only work for one of them. If one of the other users need to interact with NetworkManager, they are screwed.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Boot system
2. Log in, nm-applet loads and connects automatically
3. Log in as another user, keeping previous user logged in
4. Look in vain for the applet. Starting nm-applet from the command line won't work.

Actual Results:
No NetworkManager applet.

Expected Results:
NetworkManager applet in all its glory.

Additional info:

This might be related to bug #449976 concerning the inability to set whether the
NetworkManager applet appears on a per-user basis.

*** Bug 460843 has been marked as a duplicate of this bug. ***

This bug drives me crazy. If I leave my computer going, and the screen locks, then someone else (who logs in with their own username) can't control the wireless network. Dialog boxes pop up in the person who first logged in. Please please fix!

Has this bug been fixed for Fedora 10? Would really really love to see it fixed.

Rod Hull (iwantmyjelly) wrote :

This is a massive bug IMO.

Now that Intrepid adds the new fast-user-switch applet as the power button (so is essentially the default behaviour), and thus fast user switching is now actively encouraged, it seems crazy that something essential like a network tray icon is not available for all users at once...

The old version of nm-applet worked FINE under Hardy when switching users...

It seems not.
At least, in sources (look here: [path for sources of network-manager-gnome]/src/connection-editor/main.c), in lines 95-107 are conditions for only single-instance launching of applet, and output of that string "Could not acquire the NetworkManagerUserSettings service as it is already taken".
Also, I confirm that there wasn't such bug in hardy (but it was 0.6.6 version of NM, instead of 0.7 in intrepid)

Also, it's clearly said in ChangeLog:

2008-07-27 Dan Williams <email address hidden>
* src/connection-editor/main.c
                - Implement a single-app-instance object that exports a D-Bus API to
                        accept the same args that the connection editor does on the command
                - (main, try_existing_instance): if a connection editor is already open
                        in the current session, just send the command-line arguments to that
                        existing editor over D-Bus instead of spawning a second editor

Alexander Sack (asac) wrote :

are you sure that nm-applet isnt running for both users? maybe its just that the tray thing isnt displayed?

Changed in network-manager:
importance: Undecided → Medium
status: New → Incomplete
Stepan Zastupov (redchrom) wrote :

Yes i'm sure, nm-applet refuse to launch (even vy hand) with error.

Alexander Sack (asac) wrote :

> Yes i'm sure, nm-applet refuse to launch (even vy hand) with error.

=> This doesnt prove its running... check that NO process is running instead.

Of course I mean that another process is running. nm-applet should
refuse to run if another proccess is running on the _current_ session.
I mean that nm-applet should acquire session service, not system.

2008/11/5 Alexander Sack <email address hidden>:
>> Yes i'm sure, nm-applet refuse to launch (even vy hand) with error.
> => This doesnt prove its running... check that NO process is running
> instead.
> --
> nm-applet fail when another user is logged in (intrepid)
> https://bugs.launchpad.net/bugs/284596
> You received this bug notification because you are a direct subscriber
> of the bug.

I can confirm this. it's not working on my computer either even when you try to start it by hand, and it's not a listed process for that user.

Changed in network-manager:
status: Incomplete → Confirmed
Brice Terzaghi (terzag) wrote :

I have the same error message (trying to start nm-applet manually as the icon doesn't appear in the panel) but have only one user on my system...
Using Intrepid Server + ubuntu-desktop package installed.

Changed in network-manager:
status: Unknown → Confirmed


This bug still apply to Fedora 10 unfortunatly.
I also suffer from this bug ...

Thank you very much for your help !

This one's a royal pain, eh?

I want to tell you about how I have worked around this bug. It is a workaround, not a fix.

 - Create a script called /usr/local/bin/grab-network

  #! /bin/bash

  sudo killall -1 nm-applet
  sleep 1
  nohup nm-applet < /dev/null > /dev/null 2>&1 &
  sleep 1

 - chmod a+x /usr/local/bin/grab-network

 - Run visudo, and add these lines:

    Cmnd_Alias GRAB_NETWORK = /usr/bin/killall -1 nm-applet


    # Allows people in grab_network group to restart wireless.
    %grab_network ALL = NOPASSWD: GRAB_NETWORK

 - Create a new group in /etc/group called "grab_network".

 - Add users who you want to be able to grab the network, to this group.

 - On the desktop for each of these users, create a launcher to /usr/local/bin/grab-network.

As I said, a workaround, not a fix.

Cameron Braid (cameron-braid) wrote :

I think this bug should have a higher priority than medium.

It is a real pain that wireless networking stops when I switch users.



Hi !

thanks for the workaround.

In fact this bug is not very annoying as long as the user who logged first is still logged. But when this user log out other users cannot use the network any more unless they log out and in again.

Still, should a bug zapper or the maintener mark this bug as belonging to F10 so that it is still valid when F9 will be end of life ? Thanks !


This bug may be solved..

I did experience it earlier, but now using:

Fedora 10 on #1 SMP



I do not longer get this problem. NetworkManager icon appears whatever user I switch to.

Can someone else verify this?

still persist for x86

[axet@axet-laptop ~]$ rpm -qa|grep Network

Same for me on x86 it still persists with the latest NetworkManager packages

I thought perhaps me running Compiz-Fusion was the thing.. not sure if that was correct..

I turned off Compiz-Fusion (via the Desktop Effects control in the System menu) and the problem did returned.. though, once I turn on Desktop Effects again.. the problem stayed.

So now I again have the same problem. I can not reproduce this, even after reboot. I keep getting the missing NetworkManager icon all the time now.

My "Compiz Fusion" installation includes




When I didn't have the problem I got a notification about connected established to my Wireless network.

Changed in network-manager:
status: Confirmed → Triaged
zombiepig (nyall-zombiepigs) wrote :

This bug is serious under the following circumstances:
- First user logs into PC, network manager starts up and connects to network
- Second user uses fast-user-switcher to logon, has no icon for network manager
- Some time later the first user switches back on, and logs out of their account
- Now, the second user has no network manager, and the network connection is lost. They've got no way of re-connecting to the network, save manually starting nm or logging out and logging back on.

I'm hitting this situation a lot with two users using the same netbook and wireless network connection.

ajm-b (rascassian) wrote :

Agreed. It's also a big problem when:
- User A logs into the machine and connects to network
- User B logs into the machine
- User A or user B puts the machine to sleep
- User B wakes the machine but can no longer connect to the network, user A has to log in for this to work.

*** Bug 453985 has been marked as a duplicate of this bug. ***

José Lou Chang (obake) wrote :

This is the most annoying bug I have encountered in Ubuntu 8.10.

The first user that log-on has the network applet where you can switch between networks,
but the second user does not have the network applet unless the first users logs out first.

My family is starting to hate GNU/Linux because of this bug.
It should be high priority to fix this.

Good luck guys.

*** Bug 372171 has been marked as a duplicate of this bug. ***

Changed in network-manager:
status: Unknown → Confirmed

*** Bug 490850 has been marked as a duplicate of this bug. ***

José Lou Chang (obake) wrote :

I see that the status of this bug has been changed to "Triaged", did the fix gets released for the current Ubutu 8.10?

I suppose Ubuntu Jaunty will not have this problem :)

"Triaged" merely means that we have enough information on the bug for a developer to start working on it...

Ralph Little (rlittle) wrote :

> My family is starting to hate GNU/Linux because of this bug.
> It should be high priority to fix this.

I second this. It's confusing for the family because if they get connection failure for the user that did get the network-manager, they have no way of reconnecting it when logged in as themselves.

I'm trying to convince the family that this is better than Windows and up until now, it has been really good and they're convinced.
OK, whinge over...

same in rawhide with:


try to run nm-applet while another user is logged in result in:

** (nm-applet:5442): WARNING **: <WARN> applet_dbus_manager_start_service(): Could not acquire the NetworkManagerUserSettings service as it is already taken. Return: 3

Fedora Bugzappers volunteer triage team

Changed in network-manager (Fedora):
status: Confirmed → In Progress
H Koch (h.koch) wrote :

I have the exact same problem in jaunty.
It also happens (nm-applet refusing to start)
if a kde user starts knetworkmanager first (on the same laptop).

Several kde users can run knetworkmanager simultaneously.
So I ended up switching from gnome to kde.
But it turns out that only the knetworkmanager that was started first
can take any action (re-connect, choose another network, ...)
if the connection goes down.

Such a problem was already reported on 12/4/08 with
(Apparently things worked in 8.04.)
This seems like a serious problem to me.

Or is Ubuntu becoming a single user operating system?

H Koch (h.koch) wrote :

An addition to my previous post:

No changes to my statements concerning nm-applet.
But the problem with knetworkmanager (or plasma networkmanager applet)
can be avoided. Just in case somebody is interested:

As I learned, there are two types of connections, user and system.
With a system connection, any authorized user can start/stop it,
and it persists if the user that started it logs out.

The default seems to be user. On my jaunty installation,
the system option (allow other users) is greyed out or invisible,
depending on the tool being used, even for the user that has administrative privileges.
Under kde4, I could not find any tool for creating a system connection.
But under gnome, the nm-editor (I think) has this option.
Having to start a gnome session for this is annoying, but it works.

As H Koch wrote, I'm still observing this bug in Jaunty (9.04)! That's three or four releases in a row where I've had to contend with at least one serious bug in user switching. Is there any progress on resolving this one?

No progress AFAIK, see the upstream report in GNOME bug tracker. They're aware of it since duplicates appear regularly. You may still ask them why it's not on the priority list, but they're quite busy working on things like Bluetooth support ATM.

Have you tried setting the connexion for all users, as suggested in the previous comment? At least, that makes this serious limitation less problematic.

"Have you tried setting the connexion for all users, as suggested in the previous comment? At least, that makes this serious limitation less problematic."

That's true, I guess. But the fact that I have to install something other than NetworkManager for the second user to manage the connection (I'm not using Kubuntu), and the fact that connections must be individually "whitelisted," still makes the experience very frustrating.

At least there's some work-around. For now I think it will be easier to log out and log in as a different user every time rather than having multiple users logged in, since I've also had another bug with user switching that left one user with no X session until I restarted the system. I haven't reported that one because I haven't been able to track down its cause or reproduce it yet.

I know my complaining isn't really helping to fix the problem, but this is a frustrating state of affairs, considering Linux's multi-user roots. I have to wonder why the upstream bug is marked with severity "Enhancement," considering its impact.

Thanks for the update.

terdon (terdon) wrote :

The bug is even more serious. I am running a single user system under Linux Mint 7 (essentially jaunty). My kde session is broken unless nm-applet is running. That is, I just get a black, unclickable desktop since kde now relies on the network for some info.

From what I have read here, this is because nm-applet can't load if I have already once logged into gnome and run network manager right? So, what should I kill in order for nm-applet to load? ifconfig wlan0 didn't help, what is the name of the process that is blocking me?

terdon: i don't think your problem is the same as this one. The system may need network to be running to work, but that's not the same kind of network; this one is called 'lo' and is started automatically without NetworkManager running.

Please open a new report, it will be easier to debug. BTW, you can try 'killall nm-applet' to stop the applet, if that's the problem...

terdon (terdon) wrote :

Milan: I don't think it has anything to do with lo. The problem is that unless I boot straight into KDE, NetworkManager wont run. That is, if I log into GNOME and then switch to KDE => no network ==> no KDE. On the other hand if I go straight into KDE then I can connect with no problem. Isn't this the behaviour you have been experiencing?

And, the problem is that nm-applet is not running and yet I cannot run it to get online.

I understand the causality you're seeing here, but I don't really see how you can be sure that nm-applet is the culprit here. A few things to test:
- How can you be sure that NetworkManager does not start, if the whole desktop is blocked?
- Does starting KDE, then going to GNOME breaks the same way?
- Do you see any error messages in ~/.xsession-errors after starting KDE the second time? (get it from the console)

Basically, KDE should not rely on the network to work (obvious). So the problem can be that the applet tries to start and for some reason hangs and blocks the desktop with it. But that's strange, since I don't believe that the whole desktop is so fragile WRT applets.

Again, please open a new report and post its address here. No need to spam all the people with something that's not stricly the same bug.

terdon (terdon) wrote :

- How can you be sure that NetworkManager does not start, if the whole desktop is blocked?
  Well, I have gnome-do and keyboard shortcuts which allow me to move around. It is only the desktop itself that is locked. I can get a terminal and run ps commands ok.

- Does starting KDE, then going to GNOME breaks the same way?
  Yes, in the way described in this bug. If I load one WM first and then switch, the other has no network

- Do you see any error messages in ~/.xsession-errors after starting KDE the second time? (get it from the console)
  Yes, loads, will not post them here.

"Basically, KDE should not rely on the network to work (obvious). "
 Absolutely, yet it does... I think it is part of the fancy new desktop the folks at KDE have created.

"Again, please open a new report and post its address here. No need to spam all the people with something that's not stricly the same bug."
    Fair enough, I will. But I still think that what I am experiencing is connected. I have now fixed it, but when I first logged on to kde it was broken. Running nm-applet fixed it. Sounds like its another effect of the same bug to me. If it isn't sorry for the spam. I will shut up now :)

(In reply to comment #15)
> same in rawhide with:
> NetworkManager-glib-
> NetworkManager-gnome-
> NetworkManager-
> try to run nm-applet while another user is logged in result in:
> ** (nm-applet:5442): WARNING **: <WARN> applet_dbus_manager_start_service():
> Could not acquire the NetworkManagerUserSettings service as it is already
> taken. Return: 3

Maybe it's another bug but I too get this error message (only single user, no locked screen etc) whenever I want to start nm-applet.

I'm running f11 (fresh install) and version NM 0.7.1-4.git20090414.fc11. In f10, everything was fine.

A remark regarding authorization:

If a connection has been made and the user chooses to fast-user-switch to another account, this other account should not be able to tamper with already established connections, only if he has the appropriate rights to do so (via policykit).

*** Bug 508294 has been marked as a duplicate of this bug. ***

>> My family is starting to hate GNU/Linux because of this bug.
>> It should be high priority to fix this.
>I second this.
I third this.


It is annoying and weird having to say it does not work. It is annoying not being able to use it if you are the second user to log onto the machine.

This needs to be fixed. It needs a higher priority.

Jacobo de Vera (jdevera) wrote :

This was annoying me too, so until we get a fix for this, you can try this workaround I documented here:


It is by no means a solution, but it might bring the family back to Linux :)

Facundo Batista (facundo) wrote :

I have karmic fully updated, and the problem is still here:

$ ps -eaf | grep nm-applet
monica 3875 3744 0 Sep25 ? 00:00:04 nm-applet --sm-disable
facundo 18231 18201 0 09:48 pts/1 00:00:00 grep nm-applet

("monica" is the other user using the system)

facundo@exepus:~$ nm-applet

** (nm-applet:18249): WARNING **: <WARN> request_name(): Could not acquire the NetworkManagerUserSettings service as it is already taken. Return: 3

Martin P (martin-pittamitz) wrote :

>>> My family is starting to hate GNU/Linux because of this bug.
>>> It should be high priority to fix this.
>>I second this.
>I third this.

Bug #508294 was reported against F11, so this bug should have its Version bumped to 11 (certainly before F10 goes EOL).

I see this in F11 too.

f12 - the same

komputes (komputes) on 2009-10-09
Changed in network-manager (Ubuntu):
assignee: nobody → Alexander Sack (asac)
summary: - nm-applet fail when another user is logged in (intrepid)
+ nm-applet fail when another user is logged in
summary: - nm-applet fail when another user is logged in
+ nm-applet fails when another user is logged in

Fixing this bug requires making sure that NM properly interfaces with ConsoleKit to get to know when a session changes state.

I've been working on a fix when time permits: changing the DBus name registration flags to ALLOW_REPLACEMENT and REPLACE_EXISTING instead of DO_NOT_QUEUE, as well as to listen for a signal on the bus when ConsoleKit.Session sends ActiveChanged in order to know when to re-request for the bus or leave it to another applet to use...

So far, my tests have been unsuccessful. Somehow I never see the ActiveChanged signal from ConsoleKit, although I do get the Lock/Unlock signals from the GNOME Screensaver, for example.

Unless I'm misunderstanding something?

H Koch (h.koch) wrote :

Five months ago I switched from gnome to KDE because of this problem.
The KDE version of the nm-applet worked fine, and still does.
How about asking the KDE people how they do it?

Alexander Sack (asac) wrote :

for this nm applet must be able to use without having its own usersetting service running. so if it notices that it cannot claim the user settting service name it needs fall back to "just system settings" mode ... unless we want to tear down the other name owning applet - which could be a potential solution too.

Alexander: ideally, you'd really need the applet from the active user to claim the D-Bus interface, which implies it also allows other instances to replace it when ConsoleKit reports that it's no longer the active one. D-Bus allows for that.

Definitely still in F11. I did something similar to comment #5 some months ago but forgot to check for the existence of the bug. It is absolutely related to fast user switch, specifically the nm-applet can only be executed once, but must be owned by the currently active user.

max ulidtko (ulidtko) wrote :

The bug still in Karmic?.. Ooh, guys, it's really, really upsetting :( Annoying very much, you know.
I wish you completed the D-Bus wars as soon as possible.
Waiting, gratefully.

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:

Erik B. Andersen (azendale) wrote :

I can confirm that this bug still occurs in Lucid the lucid daily iso for 11-20-2009.

sergeyfromminsk (shu-mail) wrote :

Confirm. 9.10. 64 bit

Buzz (buzz-piersol) wrote :

Confirmed for Ubuntu Netbook Remix 9.10

A system wide network manager configuration that's visible to all users editable by all administrators (both via nm-applet...) is my preference. This could allow network connections with no-one logged in and could fix this bug too.

This sounds like it's worthy of a blueprint.

There seems to be two bugs here:
1) nm-applet isn't starting for a second user (useful for monitoring).
2) nm-applet can't be used to create a network connection when nm-applet's already running as another user, even if the device in question is free. So that a) prevents hijacking (desirable for non-admin, but not for admin users), b) prevents opening free devices (desirable for non-admin, but not for admin users).

Interesting security issues:
1) Allowing any user to open/hijack network connections may allow for easier man in the middle attacks. This is really more of an issue for virtual networks and wireless networks as physical network man in the middle requires a physical connection (thus usually physical access, or an unlikely forgotten extra plugged in network connection).
2) Allowing any user to use open network connections may allow less trusted users access to a network they couldn't otherwise authenticate to. I'm not sure there's any time reasonable way to lock this down as it would require some kind of capabilities management, and possibly kernel changes.


     Drew Daniels
Resume: http://www.boxheap.net/ddaniels/resume.html

This is still broken in F13 alpha, and has been forever.

Running from the command line for the second user gets:
% nm-applet
An instance of nm-applet is already running.

Of course the other instance is for the first user so no help at all.

Is there any plan to address this since it's a gaping hole in fast-user-switching support (which otherwise works excellently these days)?

H Koch (h.koch) wrote :

This nm-applet situation beats anything
I have encountered in 15+ years of using Linux.
A bug in a relatively simple program stays for 3/2 years
and severely impacts the usability of an entire desktop environment
on any multi-user system that depends on wireless access.

My dektop machine at home is kept busy all all day with extended tasks
such as homework, recording music, watching tv episodes, etc.
For quick things like checking email, getting driving directions,
looking up a recipe, etc, my family uses a shared laptop.
It is opened (and closed) dozens of times each day,
and with user switching taking just two seconds,
everybody feels like having their own laptop.
I can't think of a better commercial for Linux
than seeing something like this in action.
Most people are simply not aware of this possibility.
It is significantly cheaper than what they do:
buy each family member their own PC or Mac.
But now imagine what people think
when they see my wife and kids struggle with something as basic
as connecting to the home network.
Not to mention our own frustration.

Don't tell me that there are just 64 "affected users".
I felt like screaming when I read this in a recent email message.
What a great excuse for ignoring the problem.

Another lame excuse: security concerns.
As I mentioned already last year,
KDE's network manager applet does not have this problem.
Under KDE, I can connect to the home (or any other) network
by treating it either as a "user connection" or "system connection".
The user connection, which is the default,
blocks others from doing anything to this connection.
Not so with the "system connection".
As system administrator (root) I can declare the home network
to be a system connection, once and for all,
allowing others to connect/disconnect,
and allow the machine to connect automatically to the network,
no matter who logs in/out or who opens/closes the lid.
The point is that I have a choice!
Why can't this be done under gnome?

I bet that the nm-applet has a serious design flaw,
and that the current bug will only be fixed
as part of a new design, at some unknown time in the future.
In retrospect, it seems clear that it was known 3/2 years ago
that the situation will drag on and on as it did.
Be it as it may,
I would appreciate hearing what the real problem is
and who is planning to do what about it.
I am aware that work like this is done by volunteers.
I would be willing to contribute $50, or more,
and maybe others could do the same,
if this is what it takes to get this problem solved soon.

Great argumentation.

I totally agree with you. Add other $50 to yours (PayPal ready). :)

Let's take it a good feeling.

Tomi Juntunen (tojuntu) wrote :

Nice argument indeed.

Gonna chip in too for that!

Still broken in F13 release, any updates?

The feature is not implemented yet.
Nevertheless, the subject is currently being discussed on the networkmanager-list:

Mark Faine (mark-faine) wrote :

I'm amazed that such a show-stopper critical bug has gone unfixed for so long. I just didn't think such a thing could happen.

José Lou Chang (obake) wrote :

I have hope in you all. I know that this will be fixed someday.

In the mean time, we could use wicd [http://wicd.sourceforge.net/] instead of mn-applet. It is in the Ubuntu Repository.

I haven't tried this one, but WiFi Radar [http://wifi-radar.berlios.de/] might work as well.

Wicd has very limited WiFi support. Last time I checked it didn't allow to use WPA connections, so it's just useless for me.

On 10-07-02 08:27 PM, Michał Gołębiowski wrote:
> Wicd has very limited WiFi support. Last time I checked it didn't allow
> to use WPA connections, so it's just useless for me.

Wicd definitely supports WPA - I'm using it right now. I'd much rather
see the bugs in nm-applet fixed, since the interface is so much nicer,
but until they are, wicd is a reasonable alternative.

Jon-o Addleman - http://www.redowl.ca

Anyway, I still need Eduroam connection at my University and in Wicd it's not so easy to set up.

Joseph Grafsgaard (grafsgaard) wrote :

Confirmed for Ubuntu Netbook Edition 10.04

Confirmed in a fully updated Lucid desktop.

dugger5688 (dugger) wrote :

This should really be high or critical since it severely limits the ability to deploy ubuntu as a multi-user desktop system for a household that doesn't have a resident techie. It also is such a fundamental package that should really work 100% of the time no matter what.

Changed in network-manager (Ubuntu):
assignee: Alexander Sack (asac) → nobody
Changed in network-manager:
importance: Unknown → Wishlist
Arve Seljebu (arve-seljebu) wrote :

The thing that freaks me out, is if a normal user logs in to the desktop first, and the administrator later(read me), he is not able to use nm-applet. How irritating isn't that?

Sure, you can use "sudo killall nm-applet && nm-applet &", but taking over the control should be an option on the indication bar.

Igor Wojnicki (wojnicki) wrote :

This design flaw is SERIOUS! In my opinion it prevents using nm at all...

Me and my wife share a netbook (Ubuntu 10.10), and are usually both logged in and just "switch user". Everything works great until the first logged in user logs out. The netbook including the second user is then disconnected from the wireless network, and since the second user doesn't see any network manager applet in the GUI it not obvious how to reconnect. The only solution I have found that doesn't require opening a terminal shell is to log out and log in again. The very least there should be a way to restart the network manager applet in the GUI. This is a major flaw unless Ubuntu has a stated goal to be a single user system.

H Koch (h.koch) wrote :

Just checking back, every 6 months, ...
I suppose it is still a "feature" of the nm-applet
(after 2 years it cannot be considered a bug)
that it shall start only for the user that logs in first,
and that the others deserve to be kept in the dark.
(Not to mention being offered any functionality.)
If so, I recommend tossing gnome and using KDE.

I can't believe this is two years old. This should be the #1 papercut, easy to fix or not.

berend (berenddeboer) wrote :


I get sick of this bug too.

Alen (cshadow) wrote :


Shompol (shompol) wrote :

Here's my workaround:
Add a shortcut on all user's desktops, when clicked it will execute command:

sudo pkill nm-applet;sleep 2; nm-applet&

The drawback is that the user will need administrative privilege, and will be required to enter his password to restart nm-applet under his UID. The original user will have nm-applet "stolen" from him....

Igor Wojnicki (wojnicki) wrote :

To overcome the the problem with the administrative privileges, 'pkill nm-applet' can be saved as a script (lets say in /usr/local/bin), and then its name along with all usernames can be added to /etc/sudoers.

However there might be a better solution: hack the consolekit to do all the killing/restarting for the user. So upon switching a user the nm-applet should be killed and then restarted with the new user privileges. I'm not sure if it is doable with the consolekit though.

Keith Allcock (keith-allcock) wrote :

Only just bothered to set up multiple users on my netbook, and really surprised at this issue.

What is the purpose of the NetworkManager service, if the nm-applet isn't just a client for it ?

DrH (alan-hood) wrote :

We are affected by this bug too using Ubuntu 9.10. Very surprised that it has lingered so long. This bug is not a paper cut. At minimum, the user is annoyed. For some, the user experience is seriously negatively impacted. Not fixing this issue could be due to insufficient resources for fixing the issue or an unwillingness to prioritize this issue. Alternatively, this issue may considered a feature, rather than a bug.

I can consistently reproduce Alan J's scenario detailed on 2009-01-20 in Ubuntu 10.10.

This is to be addressed in NM 0.9 I think? Hopefully that will be in F15 but as of F14 this is still broken,

firemankurt (kjensen-iaff106) wrote :

Hoping that this would be fixed in Mint 10 (Julia).

Not so much..... :( (still broken)

Fresh install of LinuxMint R10 w/ Linux 2.6.35-22-generic on AMD Athlon 64 (64 bit version)

When switching users "nm-applet" fails to show up for second user.

This is a major annoyance for my family as many others have expressed. This one bug makes me hesitate to recommend Linux to more friends because network control just has to be easy for novice users.

My work around till a fix comes is to add "nm-applet" as a menu item under accessories.
At least I can train my family to open it there if it does not show-up automagically.

Thanks teams for all your hard work...... I love Linux Mint and loath anytime I have to use Winblows at work.

Robert Pollak (robert-pollak) wrote :

NetworkManager 0.9, planned for March 2011, wants to fix this, see http://live.gnome.org/NetworkManager/ApiSimplify.

Justin Krehel (jkrehel) on 2011-02-11
Changed in linuxmint:
status: New → Triaged
importance: Undecided → Medium
iroli (roland-lezuo) wrote :

This bug is especially annoying when using VPN connections, as the second user logged in simply can not start VPN connections configured via nm-applet.

ron (its4ron) wrote :

Dear unassigned i was surprised to see that this has been a known problem for years! i think i will try kde. if that does not work i think it is bye bye ubuntu. i have been using ubuntu since 7.06 on the same hardware and 10.04 and 10.10 have been upgraded to invite me into this group... i think the number of affected is much higher - i had a hard time diagnosing and id ing this awful bug.

sure seems more important than a unity desktop! i have spent hours with this lousy bug.

Fabián Rodríguez (magicfab) wrote :

I hit this bug again in the following situation: a customer requested individual desktops to be setup for Internet access and general web/text editing tasks. We setup one admin user and one regular user and only gave credentials for the regular user. When using the (second) regular user, NM is nowhere to be found and network connectivity is that much harder to configure.

This is with 10.10, we used this workaround:

1) Physically connect to a wired connection
2) Obtain a DHCP lease (sudo dhclient from command line, in Applications > Accessories > Terminal)
3) sudo apt-get update
4) sudo apt-get install wicd

Also make sure the second user has appropriate rights (under System > Administration > Users and Groups > Click user > Advanced settings > User privileges ).

WICD acts as a replacement of network manager. To read more about it **and how to use it**, see:

Linuxexperte (andrea-koeth) wrote :

hi Fabián Rodríguez,

have you got a Dock activated or do you use the regular gnome-panel??

For having the nm-applet in awn for example just do this: go to the settings-button of your awn-Dock, rightcklick it and press "dock-settings" Then go to to "applets" and ther from the list, you just have to select the notification-area-applet. This applet includes the nm-applet. For me this works fine here in LinuxMint 10 amd64.

For setting up your internet-connection, do this:

Go to the menu and there in "settings" and there in "network-connections". There create your internet-access. If you want to be automaticly connected, click the ceckbos on the upper left corner in the first window.
Then in the very last window, look closely at the very left down corner. There you see a checkbox saying "use this connection for all users of this PC". Check this box and close the dialog clicking on "OK".

Then go back to your Dock or to your Gnome-Panel and click on the nm-applet (in awn it is included in the notification-area-applet). Then it should see your network. Then a window pops up, asking you to insert your network-key. Insert it and press "connect".

This is it and you have Internet-access.


Correct, this is addressed in 0.9 and Fedora 15 and later. It works there, but it won't ever work in NM 0.8 and earlier (f14/f13). Given that, I'm going to mark as fixed since it's been working in F15 for a few months already. A large part of NM 0.9 was rearchitecting to make stuff like FUS possible.

AlexWinner (scukonick) wrote :

>This bug is especially annoying when using VPN connections, as the second user logged in simply can not start VPN connections configured via nm-applet.

I also have this bug at Ubuntu 11.04

Aaron Kelley (aaronkelley) wrote :

This bug has recently been marked fixed upstream in Network Manager 0.9. Hopefully we'll get that packaged into the next version of Ubuntu.


Changed in network-manager:
status: Confirmed → Fix Released

Indeed, this is addressed in NM 0.9; available in Oneiric.

Since the upstream bug is closed I'll now close the bug task for Ubuntu.

Thanks for filing this bug and helping to make Ubuntu better!

Changed in network-manager (Ubuntu):
status: Triaged → Fix Released
Changed in linuxmint:
status: Triaged → Fix Released
Changed in network-manager (Fedora):
importance: Unknown → Medium
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.