pvcreate: Couldn't open physical volume - Permission Denied

[krishna_bng]

Hi.

I have an rx4640 connected to hsv110 with securepath s/w. I am able to access one of the raid units on the EVA. The second and third raid units created on the EVA are visible in the ioscan and spmgr commands but am unable to run pvcreate successfully. I get the following error:

# pvcreate /dev/rdsk/c10t0d1
pvcreate: Couldn't open physical volume "/dev/rdsk/c10t0d1":
Permission denied

However, I am able to successfully create pv and vg on /dev/rdsk/c10t0d0 raid unit from the same HSV controller.
-----------------------------------------------

Pls find herewith output of spmgr & ioscan attached as pvcreate.txt.

I have tried the options insf -e and insf -C but in vain.

Looking for help in this regard. Appreciate a quick response

[florence mathon lermusi]

did you check the "/dev/rdsk/c10t0d1" file ?

[krishna_bng]

Hi.

I did check on the /dev/rdsk directory. Here is the output of the same.

# pwd
/dev/rdsk
# ll
total 0
crw-r----- 1 bin sys 188 0x000000 Jun 21 11:01 c0t0d0
crw-r----- 1 bin sys 188 0x0a0000 Jul 1 09:34 c10t0d0
crw-r----- 1 bin sys 188 0x0a0100 Jul 16 11:04 c10t0d1
crw-r----- 1 bin sys 188 0x0a0200 Jul 19 07:47 c10t0d2
crw-r----- 1 bin sys 188 0x020000 Jun 21 11:01 c2t0d0
crw-r----- 1 bin sys 188 0x020001 Jun 21 11:01 c2t0d0s1
crw-r----- 1 bin sys 188 0x020002 Jun 21 12:13 c2t0d0s2
crw-r----- 1 bin sys 188 0x020003 Jun 21 11:01 c2t0d0s3
crw-r----- 1 bin sys 188 0x040300 Jun 21 11:01 c4t0d3
crw-r----- 1 bin sys 188 0x060300 Jun 21 11:01 c6t0d3
-----------------------------------------

Another observation is that when I do a vgscan, i get an error like:
# vgscan
lvm: /dev/config - permission denied.
Unable to scan "Physical volumes" on system

Thanks for an early response to resolve this error.

Regards,
Krishna

[krishna_bng]

Here is the listing of /dev/config:
# ll /dev/config
crw-r--r-- 1 root sys 69 0x000000 Sep 4 2003 /dev/config

[Zeev Schultz]

It looks rather strange.On one hand,the fact that you can see second LUN means that on the fabric zone level you have access to the LUN (FLOGI,PLOGI etc).I would anyway verify that everything is ok with zones.Check also supportShow/portErrShow outputs (if switch is Brocade).Is this LUN presented somewhere else,another host and works there?

I would check on the EVA Management Appliance how the second LUN is presented to the hosts.I saw in the spmgr output that both LUNs work through /dev/td1 controller so it shouldn't be the 2nd HBA issue.

When you run fcmsutil /dev/td1 get remote all I assume you can see both LUNs?
Any messages in the syslog,from either SecurePath,FC driver etc?

[florence mathon lermusi]

what are the results of "diskinfo" and "fuser -uv" on /dev/rdsk/c10t0d1.

did you check if the vdisk is presented as a read/write device ?

[krishna_bng]

Hi.

It was noticed that the system was behaving very inconsistantly and none of the commands used to work normal.

Accidently we discovered that the user (ISV) had changed the permission of some of the files under /sbin to oracle:dba. This was causing all the trouble. Everything came back to normal when we set those files permission back to bin:bin

Admit that this was too administrative in nature. Nevertheless this is the first time we encountered such issue and error.

Thankyou all for the timely support & valuable suggestion.

[florence mathon lermusi]

i don't know if this can help, but swverify can be helpful to check the perm of your files...

[KapilRaj]

insf -e ## Check it

Kaps