Got a file on an NFS mounted directory which I am trying to use utl_file on to rename it to another NFS mounted directory
e.g. source directory
Code:
[xx1@xx1 in]$ ls -l
total 24
-rw-r--r-- 1 550 its 4033 Jul 7 16:04 file1.xml
[xx@xx1 in]$ ls -ld
drwxrwxrwx 2 550 its 8192 Jul 11 12:25 .
Trying to move it to this directory
Code:
[xx@xx1 in]$ cd ../success/
[xx@xx1 success]$ ls -ld
drwxrwxrwx 2 550 its 4096 Jul 11 12:22 .
So the directories have full permissions on them. I am not the owner of the file nor am I in the same group but from the command line I can move the file using mv and the file gets moved
however when I try to do it using utl_file
I get an error
e.g.
Code:
declare
v_file varchar2(100);
v_direc constant varchar2(80) := 'IN_DIR';
v_direc2 constant varchar2(80) := 'SUCCESS_DIR';
begin
v_file := 'file1.xml';
utl_file.frename(v_direc, v_file, v_direc2, v_file);
end;
/
declare
*
ERROR at line 1:
ORA-29283: invalid file operation
ORA-06512: at "SYS.UTL_FILE", line 18
ORA-06512: at "SYS.UTL_FILE", line 1108
ORA-06512: at line 7
Why cant utl_file move the file? If i give the file group write permission (the oracle user is in that group) then it works
What is utl_file.frename doing that is stopping this working unless the group permission is set.
Are both NFS mounts on the same physical disk, or are you crossing disk?
If you are moving a file within the same disk, the mv just changes the entry for the file in the directory structure, nothing physically happens to the file. If the move will make the file go to a different physical disk, then it is a copy/delete operation. You need write permission in the source directory to do the delete.
Attempting at all costs to avoid being a programmer, I would ask ... has the utl_file_dir been added to the init parameters, or preferably a create directory statement been executed?
"
In the past, accessible directories for the UTL_FILE functions were specified in the initialization file using the UTL_FILE_DIR parameter. However, UTL_FILE_DIR access is not recommended. It is recommended that you use the CREATE DIRECTORY feature, which replaces UTL_FILE_DIR. Directory objects offer more flexibility and granular control to the UTL_FILE application administrator, can be maintained dynamically (that is, without shutting down the database), and are consistent with other Oracle tools. CREATE DIRECTORY privilege is granted only to SYS and SYSTEM by default.
--------------------------------------------------------------------------------
Note:
use the CREATE DIRECTORY feature instead of UTL_FILE_DIR for directory access verification.
"
"Technically, every process has a real user (RUID) and a real group (RGID). These are the user and group of the person who started the process by running some program. Every process also has an effective user id EUID and EGID. By default these are the same. But if you run a program that has the SUID or SGID bits on, the effective UID or effective GID become those of the file, not of the person."
There is also a metalink note
Note:1016249.102
Subject: OPERATING SYSTEM PERMISSION DENIED ERROR ACCESSING THE DATABASE
which kind of says that forground processing verses 'background' processing can result in permission problems.
I've run into this type of problem when using NIS accounts. The group id (gid) that was set for my oracle user id was actually associated to a different gid so that when I logged into certain machines, the groups permissions were different. I had to have the admins make all of the servers have local accounts for the oracle userid, in order to eliminate the group id problems.
Reply With Quote
Originally Posted by davey23uk
Bookmarks