Root user- no permission?

[hrsetrdr]

I've been a linux user for a couple of years(Debian) but periodically set up a FreeBSD install to learn more of the Unix way. I recently installed FreeBSD 7.1-RELEASE #0(amd64) on an Intel C2D box, and am noticing that the root account doesn't seem to have necessary permissions to edit things such as the user settings or to manage groups. When I enter "users-admin" the GUI Users Settings opens, but the 'unlock' button is grayed out. Also, in the terminal I get the output-[WARN 2405] Cannot lookup information for pid 2405: No such file or directory
[WARN 2405] polkit-caller.c:121:polkit_caller_unref(): caller != NULL
Not built with -rdynamic so unable to print a backtrace
Reading the Handbook has so far yielded no hints as to how to fix this. Frankly, I've never encountered such a situation; if anyone has any suggestions, I'd be most appreciative.

[jb_fvwm2]

Sounds like a PolicyKit (gnome setup ) issue. Cannot help
as I have a lot of gnome programs installed but do not
use gnome as a window manager. If you drop to a terminal (xterm)
find elsewhere the values to set in rc.conf and maybe elsewhere,
and restart gnome, stuff might be more to what you are accustomed.
...........
sorry for not knowing gnome.
2004 twm > windowmaker
2005 windowmaker > fvwm2
2006? fvwm2 > (smaller one).
besides testing downloaded .twmrc 's etc.
I never tried actually starting gnome yet.
I do run xfce4 on a freesbie(org) box though
several times a year.

[Oko]

Reading the Handbook has so far yielded no hints as to how to fix this. Frankly, I've never encountered such a situation; if anyone has any suggestions, I'd be most appreciative.
To fix what?
To manige groups open the shell and type

$ su -
password
#vi /etc/group


If you are still unable to edit /etc/groups check the flag on the file. You might need to change it
to something else. How to do that is whole another story.

[Djn]

Just guessing from the sounds of that - do you have a working /proc directory?
If not, try adding
none /proc procfs rw 0 0
to /etc/fstab, then reboot and try again.

(There's not many things on FreeBSD that use /proc, so it's not set up by default. Polkitd is an exception, though.)

[hrsetrdr]

Thanks to all for your replys, it does appear to be a Gnome PolicyKit issue, but getting admin things done in a shell works fine. just adding a user to the Wheel group pw user mod username -G wheel was all I needed. I guess I jumped-the-gun in assuming the unassumable...:-r

[cajunman4life]

Just guessing from the sounds of that - do you have a working /proc directory?
If not, try adding
none /proc procfs rw 0 0
to /etc/fstab, then reboot and try again.

(There's not many things on FreeBSD that use /proc, so it's not set up by default. Polkitd is an exception, though.)

Why reboot? After you place that entry in /etc/fstab, as root type:

mount /proc

And it will be mounted without reboot. There should be very, very few things you need to reboot to accomplish.

[Djn]

You also need to restart polkitd and a few other gnome daemons that depend on it, and I suspect they're picky about the order they're done in. Having him spend a few minutes rebooting a desktop seemed easier than digging into that. ;)

[SirDice]

You also need to restart polkitd and a few other gnome daemons that depend on it, and I suspect they're picky about the order they're done in.
As of GNOME 2.20 (I think) polkitd isn't a seperate process anymore. It should all be handled by HAL now.

Having him spend a few minutes rebooting a desktop seemed easier than digging into that. ;)
I agree :e It also makes sure your configuration is correct when everything boots and works correctly ;)

[hrsetrdr]

Just guessing from the sounds of that - do you have a working /proc directory?
If not, try adding
none /proc procfs rw 0 0
to /etc/fstab, then reboot and try again.

(There's not many things on FreeBSD that use /proc, so it's not set up by default. Polkitd is an exception, though.)

I made this edit to /etc/fstab, and also mount /proc and even rebooted, but the one gnome applet I mentioned still remains "grayed out". Upon reboot, the output: glib critical: g_hash_table_destroy: assertion 'hash_table=null' failed no longer displays, however. There was reference to "console kit, something about the PID(976) hald dameon; wish I could have 'captured' that in /etc/syslog for the precise output.

I'm not really concerned about the gnome applet, just curious about the 'whys & hows' since I likely have to be my own tech support. ;)

[Djn]

If you go to the first console (Ctrl+Alt+F1) and press scroll lock, you can scroll back quite a bit - that might be enough to see those messages.