Oracle ASM – ORA-19504: failed to create file – SVR4 Error: 13: Permission denied

During one of our 11gR2 database restore activity we found below error message in the RMAN “duplicate database command”

channel aux4: ORA-19870: error while restoring backup piece /oraclone/ORCL/rman_clone/ORCL_F_20170605_c1s60alv_1_1
ORA-19504: failed to create file "+DATA3"
ORA-15045: ASM file name '+DATA3' is not in reference form
ORA-17502: ksfdcre:5 Failed to create file +DATA3
ORA-15081: failed to submit an I/O operation to a disk
ORA-27091: unable to queue I/O
ORA-27041: unable to open file
SVR4 Error: 13: Permission denied

Our Source and target database are on 11.2.0.4 and we ran “duplicate database” command to clone from source to target.

Intriguing thing was restore was not failing for all the data files that were being restored to +DATA3 ASM diskgroup. Some of the data files that were getting restored to this AMS disk group were getting successfully written while some other were producing above kind of error when RMAN restore process was trying to write to this Disk Group.

On verifying further it was found that two new disks were added to this diskgroup +DATA3 earlier in the day.

Next step was to verify what disks were under this disk group +DATA3 (DISKGROUP # 10)

SQL> select DISK_NUMBER,PATH from v$asm_disk where GROUP_NUMBER=10;

DISK_NUMBER PATH
----------- ---------------------------------
 7 /dev/rdsk/emcpower72a 
 0 /dev/rdsk/emcpower111a 
 1 /dev/rdsk/emcpower112a

Running simple “ls -ltr” command on the disks path given above showed that these above paths were pointing to actual disk:

Disk_Number 7 points to>> crw-rw---- 1 oragrid dba 326, 576 Jun 7 11:14 /devices/pseudo/emcp@72:a,raw
Disk_Number 0 points to>> crw-r--r-- 1 oragrid dba 326, 888 Jun 7 11:14 /devices/pseudo/emcp@111:a,raw
Disk_Number 1 points to >> crw-r--r-- 1 oragrid dba 326, 896 Jun 7 11:14 /devices/pseudo/emcp@112:a,raw

As you can see that two new disks (disk # 0 and 1) that were added to this diskgroup do not have the WRITE permission given to “dba” OS group.

On this system we have two OS user: oracle and oragrid. Oracle manages database and is part of “DBA” group. Now since the two new disks were not given write permission for “DBA” group so ‘oracle’ OS userid was not able to write to above two new disks and RMAN was producing error messages.

After we provided write permission on above two disks, RMAN restore process went fine.

$ chmod g+w <disk_name>