vgscan: /etc/lvmconf//lvm_lock: Permission denied

[Greg Roberts]

I get this error (vgscan: /etc/lvmconf//lvm_lock: Permission denied) when I try to run vgscan -v on a HP K470 running 10.2. The vg00 appears to be wrong and I k
need to expand a lvol. No matter what I do, delete lvmtab or lvm_lock I get the same error. I also get the permisson denied when I run vgchange and vgdisplay. Any suggestions
Thanks
Greg

[James R. Ferguson · Accepted solution]

Hi Greg:

Try this:

Make sure that /sbin/vgscan is owned by root with the setuid bit set, as:

-r-sr-xr-x 29 root sys 696320 May 10 1999 /sbin/vgscan

Do a 'chmod 4555 /sbin/vgscan' and/or 'chown root:sys /sbin/vgscan' if necessary.

...JRF...

[A. Clay Stephenson]

Greg, I once saw a problem vaguely like this.
Somehow some of the vgxxx commands lost their setuid bit. Make sure that all the /sbin/vgxxx commands are owned by root/sys and have the setuid bit set.

[Greg Roberts]

The ownership on all the vg* file was wrong so I changed it. Still get the same error , permission denied. MC/ServiceGuard might have been installed on this box years ago could this affect it?? It is no longer installed. By the way I now get an error on boot-up that says
'cannot open /dev/kmem: Permission denied'

[A. Clay Stephenson]

What are the permissions, ownership, and major/minor device numbers of /dev/kmem?

I would also check one other thing though I doubt this is a problem. Go to each /dev/vgxx
directory and make sure that you have exactly 1
group file. I once had a Jr. Admin who created an extra group file 'GROUP' with identical major and minor devices as the 'group' file and all sorts of strange behavior resulted. As I recall the symptom I saw in that case was duplicate physical volume entries in /etc/lvmtab.

You might want to do a 'strings /etc/lvmtab' and post the results; that might give us a clue. Since you mentioned MS/SG you might try a
vgchange -c n on a volume group to see if it makes any difference. At this point, I would say you have a sick installation.

Good luck, Clay

[Phil Renner]

You may need to increase the nflocks parameter in the kernel settings. We've recently had some new "buggy" applications that use too many locks and this ends up maxing out the system nflocks.