SAN file permissions getting changed

[Jeff_398]

after a change to a file, when my data base gets restarted, the permissions on the file get changed back to bin/sys. Any thoughts as to why??

[Pete Randall]

Sounds like a system related file. Which file is it?


Pete

[Jeff_398]

It is a system related file that assigns the permissions for a user group to access the allocated SAN for the raw partition

[Jeff_398]

last time the culprit turned out to be the "insf" command, which we have to run to create the device files for the new devices. We were able to avoid the problem completely on the latest SAN change by running the "insf" for the specific devices being added, so that it didn't affect any existing devices. It's still mysterious that it seemed that only the most recently added existing devices were affected each time.

Our latest incident came when we deleted a file, and then on the next restart of the db the permissions changed back. Not sure if the db set up may have something that is causing the permission reset

[Alzhy]

Jeff,

I trust that you are using said "file" as a raw device and such device is a disk device that points to SAN storage. Pretty indicative that you're probably not using any volume manager.

Can you give us the name of the "file" and the complete path to said file?

[Jeff_398]

50GB, mount as â /emc/data00â
Should contain 4 LUNâ s each on separate drive.
Each LUN managed as a RAW p

[Alzhy]

Give us:

ls -l /emc/data00
ls -ld /emc/data00
bdf /rmc/data00

[Jeff_398]

not sure what you are looking for there, but you are correct, we are not using volume manager yet, should be installed next week. we know that using the insf command should limit it to only the devices being changed, but a reboot of the db changed the permissions back

[Alzhy]

Bingo... so you are not using any volume manager yet to manage your application's (Database?) raw device access.

The EMC device you mention in all probability has its device tree recreated and along the way its permissions. If you're using LVM or even better VxVM, your access (permissions) to the raw devices will be maintained accross reboots and crashes.

The purpose of the ls -l is to establish if indeed you are not using any volume manager and other info.. Can you please post the info I am asking?

[Jeff_398]

Seems you're asking if we use LVM or VxVM for these devices. And the answer is that although we use LVM for the filesystem devices, we don't for these raw devices. And from the response, that may be something that we need to change--but it doesn't explain what happened this week.

The reason I say it doesn't explain what happend is that they're talking about the ownership not being carried over a reboot. HP also mentioned in response to my question to them that an "insf -e" is automatically run as part of reboot, and of course we know that HP documents that command could cause this. The last time the server has been rebooted was Apr. 22, so that doesn't explain what happened when they restarted the db??

[Alzhy]

HP's explanation is certainly a plausible one. Is this permissions problem occuring only on one EMC "raw" device or ALL EMC raw devices.

Also, I would have expected non use of LVM/VxVM for youe EMC Raw Devices would have meant using HP-UX device names i.e. /dev/rdsk/c10t5d0 instead of /emc/data00 - unless of course /emc/data00 is a link to /dev/rdsk/cXtYdZ? That's the reason I am asking for an ls -l of your /emc/data00.

I also have doubts whether say /dev/rdsk/cXtYdZ can maintain its non-root ownership accross reboots.

[Jeff_398]

I think the below article may explain the answer... Date: 2/14/03
Document description: Permission on disk/volume groups changes to root after reboot.
Document id: KBRC00011743

[Alzhy]

Jeff.. that KB is for VxVM 3.1 raw devices.. way old and already unsupported.

Group/raw device files permissions are fine with LVM or VxVM on HP-UX 11i since SEP 2002.

So is your /emc/data00 a link to /dev/rdsk/cXtYdZ? Why can't you give us an ls -ld /emc/data00 output so we can categorically say if you're using any volume manager or not?

[Jeff_398]

We know we are not using any volume manager, and that we need to get vm applied. We still can't figure out if a different server attached to the same SAN will affect the permissions on a seperate server, i.e. server 1 had no change, server 2 sitting in the same cabinet had a change. Server 1 had its permissions reset after the db restarted a day later

[Alzhy]

ls -l /emc/data00
ls -ld /emc/data00