Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have Fedora 17 installed on a Lenovo X230, and if I leave it configured to boot into Gnome using systemd's runlevel5.target (or graphical.target), which is the default, networking seems to work just fine -- a local user can join a new wireless network, authenticating and saving a network password as needed. So far, so good.

However, this laptop's owner prefers to boot into a non-graphical display (systemd's runlevel3.target or multi-user.target); when desired, he runs startx to get Gnome started. When Gnome is started this way, the user cannot join any new wireless network; you can select the desired SSID from the drop-down list, but no prompt for network password appears, and no connection is made. I don't see anything relevant logged in /var/log/messages.

What can be done, so that a non-privileged user who has started Gnome using startx can be allowed to join new wireless networks?


If root logs in, starts Gnome, and joins the new wireless network, then appropriate new files are created under /etc/sysconfig/network-scripts for the network and key information. Once this is done, the non-root user can use the wireless network when he logs in. This workaround is horribly inconvenient.

The user is already a member of group 'wheel' and has full sudo access without password. SELinux is disabled on this machine.

As a test, I added the user to group 'root', and made /etc/sysconfig/network-scripts group-writable. This didn't help or change anything.

share|improve this question
add comment

2 Answers

My guess is that, when you run startx, you don't have an active ConsoleKit session. See e.g. Set up PolicyKit permissions in the Arch Linux wiki entry for NetworkManager. It shows you how to use ck-launch-session in your ~/.xinitrc to make sure you have a proper CK session.

You also need to make sure that PolicyKit permissions are right, although they're probably already fine if things work from inside a Gnome session.

If the command ck-list-sessions shows a difference between using runlevel5.target versus runlevel3.target+startx, then this is probably your issue.

See also:

Administration and Privilege at the bottom of the Network Manager Configuration page.

I don't recommend that you follow what these say without understanding what they're doing, since it's not necessarily clear how they relate to Fedora, but they might be useful reading:

This Ubuntu bug: If 'startx' is run from within a text console, ConsoleKit session is not marked 'active'

This Debian mailing list post that has some details about changing policykit/consolekit permissions: Re: What is the right way to use consolekit with startx?

share|improve this answer
ya know, I did think it might have something to do with PolicyKit, but the suggestions I found didn't seem to pan out. And ConsoleKit isn't installed by default in Fedora 17, as they move toward PolicyKit. But your links helped lead me to the correct solution (and are likely useful for previous Fedora versions), so I'll happily +1 you. –  Lars Rohrbach Oct 18 '12 at 5:07
add comment
up vote 1 down vote accepted

Short answer -- use:

 startx -- vt0

Longer explanation: The links and suggestions by @JimParis led me to dig a bit more into PolicyKit and systemd, and -- crucially -- to google for "polkit startx", which led me to a result on an Arch Linux discussion site:

If you don't use a display manager, it means you won't have a registered pam session for your graphical login, which means logind won't give the correct info to polkit (it will think that there is no active session).

A workaround for this is to start your WM on the same VT as your consolelogin, and hence "steal" that pam session. I believe the magic incantation is:

# startx -- vt0

Until now, I hadn't even noticed that startx can take arguments, but this works beautifully for my situation. Not only can the local user now join wireless networks properly, but has proper access to other Gnome desktop features such as bluetooth and Suspend.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.