nm-applet fails when another user is logged in

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
                        line
                - (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

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

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

> 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.

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.

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

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

Cheers

Cameron

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.

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.

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.

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...

> 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...

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
http://ubuntuforums.org/showthread.php?t=1001556
(Apparently things worked in 8.04.)
This seems like a serious problem to me.

Or is Ubuntu becoming a single user operating system?

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.

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...

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.

- 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 :)

>> 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.

+1

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.

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

http://blog.jacobodevera.com/2009/07/30/gnome-network-manager-applet-with-multiple-users.html

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

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

>>> 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.
+1!

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?

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?

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.

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.

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

Confirm. 9.10. 64 bit

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.

Thanks,

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

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.

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.

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

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.

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.

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:
https://help.ubuntu.com/community/WICD

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.

Greetings
Linuxexperte

>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.

+1.
I also have this bug at Ubuntu 11.04

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.

https://bugzilla.redhat.com/show_bug.cgi?id=456046

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!