# Root user- no permission?



## hrsetrdr (Jan 18, 2009)

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:121olkit_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 (Jan 18, 2009)

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 (Jan 18, 2009)

hrsetrdr said:
			
		

> 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 (Jan 18, 2009)

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 (Jan 19, 2009)

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 (Jan 19, 2009)

Djn said:
			
		

> Just guessing from the sounds of that - do you have a working /proc directory?
> If not, try adding
> 
> ```
> ...



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 (Jan 19, 2009)

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 (Jan 19, 2009)

Djn said:
			
		

> 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 (Jan 20, 2009)

Djn said:
			
		

> Just guessing from the sounds of that - do you have a working /proc directory?
> If not, try adding
> 
> ```
> ...



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 (Jan 20, 2009)

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.


----------

