The investigation
Running a test procedure produced something like:ORA-29283: invalid file operation ORA-06512: at "SYS.UTL_FILE", line 536 ORA-29283: invalid file operation ORA-06512: at "TCCS.TEST_UTL_FILE", line 6 ORA-06512: at line 1 29283. 00000 - "invalid file operation" *Cause: An attempt was made to read from a file or directory that does not exist, or file or directory access was denied by the operating system. *Action: Verify file and directory access privileges on the file system, and if reading, verify that the file exists.The truss on the db process while calling the test procedure
kread(16, "\0\v\0\0\f\0\0\001\002 i".., 8208) (sleeping...) kread(16, "\0 _\0\006\0\0\0\0\011 i".., 8208) = 95 statx("/home/tccs/files/out/utlout.txt", 0x0FFFFFFFFFFE9140, 176, 010) Err#13 EACCES statfs("/home/tccs/files/out/utlout.txt", 0x0FFFFFFFFFFE8D20) Err#13 EACCES statx("/home/tccs/files/out/utlout.txt", 0x0FFFFFFFFFFE8FF8, 176, 011) Err#13 EACCES kopen("/home/tccs/files/out/utlout.txt", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH) Err#13 EACCES kwrite(16, "\0\v\0\0\f\0\0\001\001", 11) = 11 kwrite(16, "\0\v\0\0\f\0\0\001\002", 11) = 11 kread(16, "\0\v\0\0\f\0\0\001\002 i".., 8208) = 11 lseek(5, 701440, 0) = 701440 kread(5, "\00F r V\0\0\0 b r W\0\0".., 512) = 512 lseek(5, 162304, 0) = 162304 kread(5, "\0\n19 n\0\0\0 D19 o\0\0".., 512) = 512 lseek(5, 701440, 0) = 701440 kread(5, "\00F r V\0\0\0 b r W\0\0".., 512) = 512 lseek(5, 162304, 0) = 162304 kread(5, "\0\n19 n\0\0\0 D19 o\0\0".., 512) = 512 kwrite(16, "\0 �\0\006\0\0\0\0\00401".., 233) = 233 kread(16, "\0\v\0\0\f\0\0\001\002 i".., 8208) (sleeping...)The 1st investigation point was brought by the article at http://jakub.wartak.pl/blog/?p=272. But after a while it become clear that, though the conditions were met and we changed the ownership of the mount point, the problem has persisted.
The 2nd guess was by suggestion in the article on MOS:Session Accessing File On Disk Fail with OS File Permission Errors (Doc ID 392647.1). And simple check that the local user connected on BEQUEATH is able to run such procedure without problem proofed that this is the right way - after the listener restart the remote users also acquired the ability to run procedure without problems. The root cause was that the db owner was added to the group being the owner of the target directory long after the listener was started - hence the remote sessions did not acquire the proper permissions on the directory, while the local sessions with "fresh" permissions worked ok.
No comments:
Post a Comment