ERROR: vxfs mount: not super user

[Michael Elleby III_1]

Good morning-

I am trying to mount an lv that is mirrored on two disks. I have verified the configuration in the vg and ran a vgcfgrestore on the two disks in the volume group. All of the other lv's in the vg mount, but I keep getting this error when I attempt to mount the filesystem.

I have already tried removing /etc/mnttab and executing a mount -a, to no avail.

any other ideas?

Thanx.

[Pete Randall]

Not to be too obvious, but are you running the mount as root?

[Michael Elleby III_1]

Yes, I've done it via a telnet session, and I've also tried it at the console.

Mike-

[Craig Rants]

Have you checked the device files... This is just a hunch on my part, do a ll on the /dev/vgxx directory containing this lvol and see what it says...

GL,
C

[Duncan Edmonstone]

Also check that root is still UID 0:

# grep ^root: /etc/passwd
# id

HTH

Duncan

[Michael Elleby III_1]

Here is output of command:

mupr12:root > ll /dev/sicalis_old
total 0
brw-r----- 1 root sys 64 0x010005 Oct 5 2001 depot7
crw-rw-rw- 1 root sys 64 0x010000 Feb 23 2001 group
brw-r----- 1 root sys 64 0x010001 Oct 5 2001 mmsdev2
brw-r----- 1 root sys 64 0x010002 Oct 5 2001 mmsdev7
brw-r----- 1 root sys 64 0x010004 Oct 5 2001 nt7
crw-r----- 1 root sys 64 0x010005 Oct 5 2001 rdepot7
crw-r----- 1 root sys 64 0x010001 Oct 5 2001 rmmsdev2
crw-r----- 1 root sys 64 0x010002 Oct 5 2001 rmmsdev7
crw-r----- 1 root sys 64 0x010004 Oct 5 2001 rnt7
crw-r----- 1 root sys 64 0x010003 Oct 5 2001 rsicalis7
brw-r----- 1 root sys 64 0x010003 Oct 5 2001 sicalis7

The name of the lv is mmsdev2

Mike-

[Luc Bussieres_1]

I would suspect that even if you login as root the mount command was not executed with the root privileges. Either:
1) root is not uid 0
2) the mount command is suid with the owner not being root
3) the shell is suid with an owner other then root.

That's the first thing to verify..
Type uid when you are login to verify your current uid before running the mount request.

then verify the permissions of the mount command:
-r-xr-xr-x 1 bin bin 274432 Dec 6 1999 /sbin/mount

[James R. Ferguson]

Hi Michael:

What last changed? How are you trying to mount the logical volume; that is, what mount options (at command line or within /etc/fstab) are specified?

Regards!

...JRF...

[Luc Bussieres_1]

Oops I made a typo the command to us is id not uid.

[Craig Rants]

Well, I think you group file should be:
crw-r--r-- 1 root sys 64 0x010000 Feb 23 2001 group

But that is not your problem. Weird, what does a lvdisplay -v /dev/sicalis_old/mmsdev2 say?

I promise that I am not leading you on a wild goose chase...

C

[Michael Elleby III_1]

Luc - I have verified that the user id is root before I execute the mount command to mount the lv. Permissions/Ownership on /sbin/mount are 555 - bin:bin

James - First command I issued was a mountall. When that did not work, I removed /etc/mnttab and issued a mount -a, with the same results.

About a month ago, I did have an issue where I created a fs on one of the disks in the lv from a REMOTE system since this disk is in a shared configuration. I then reversed the creation, and on the original system, I was able to do a vgcfgrestore while the vg was active. I did not note any problems since the server has been rebooted since then, but never noticed that the fs was missing until I got an email from one of the dba's looking for it.


Mike

[Michael Elleby III_1]

Craig, here is info from lvdisplay:

--- Logical volumes ---
LV Name /dev/sicalis_old/mmsdev2
VG Name /dev/sicalis_old
LV Permission read/write
LV Status available/syncd
Mirror copies 1
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 2000
Current LE 500
Allocated PE 1000
Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation PVG-strict/contiguous
IO Timeout (Seconds) default

--- Distribution of logical volume ---
PV Name LE on PV PE on PV
/dev/dsk/c4t0d0 500 500
/dev/dsk/c5t0d0 500 500

--- Logical extents ---
LE PV1 PE1 Status 1 PV2 PE2 Status 2
00000 /dev/dsk/c4t0d0 00000 current /dev/dsk/c5t0d0 00000 current
00001 /dev/dsk/c4t0d0 00001 current /dev/dsk/c5t0d0 00001 current
00002 /dev/dsk/c4t0d0 00002 current /dev/dsk/c5t0d0 00002 current
00003 /dev/dsk/c4t0d0 00003 current /dev/dsk/c5t0d0 00003 current
00004 /dev/dsk/c4t0d0 00004 current /dev/dsk/c5t0d0 00004 current

[Luc Bussieres_1]

For the permissions of the group file the real value should be crw------- you don't want anybody outside of root to be able to read that file since this could be a potential security issue. Giving read permission to group and other will enable everybody that could access the system to read the disk in raw format and read everything on it even if they don't have the permissions to do it. I this case it's even worst since with everybody having write permissions they could overwrite the content of the disk.

But this is not the cause of the current problem

[Luc Bussieres_1]

Michael,

Could you also type "whence mount" to verify that you are really using the /sbin/mount.
The output should be /usr/sbin/mount and this file is suppose to be a symbolic link to /sbin/mount.

[James R. Ferguson]

Hi Michael:

Interesting -- shared volume group, vgcfgrestore done while active [not advisable].

I'd start by trying a full fsck ('-o full') on the logical volume in question to see if that fixes or reveals anything.

In the event that the above fails to find or fix anything, if you have a backup of the logical volume then I'd consider 'lvremove'ing it; 'newfs'ing it; and reloading its data from backup.

Regards!

...JRF...

[Michael Elleby III_1]

Yes, it is a link file pointing to /sbin/mount:

lrwxr-xr-x 1 root sys 11 Jan 24 2001 mount -> /sbin/mount

Mike-

[Michael Elleby III_1]

James-

I need to make a correction. The volume group is on a shared disk, but the vg is not shared.

Somehow, I had an idea this might lead to a restore from disk.

Mike

[Michael Elleby III_1]

James, started running fsck, ran into corruption items...

Will keep you posted.

Mike

[John Palmer]

Hi Michael,

This sounds like bad news to me. I suspect that somehow you've corrupted the VGDA pointers to the LV - possibly when you ran vgcfgrestore.

The only time you really need to run vgcfgrestore is when the contents of the VGDA don't match what's on the disk i.e. when you've replaced a failed disk.

Alternatively, if you somehow had this disk active on two systems, did you overwrite this LV when you created that filesystem on the other node.

Either way, this LV looks like it's gone west... hope you've got that backup tap handy.

Regards,
John

[Michael Elleby III_1]

Hey guys, just came back to assign points for assistance and to tell you how I handled this one..

I wound up removing, recreating and then restoring data from backup.. Took a day or so to get the tape since it was offsite, but you know how that goes...

So thanx guys...

Mike-