utl_file / nfs
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
Trying to move it to this directory
[xx1@xx1 in]$ ls -l
-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 .
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
[xx@xx1 in]$ cd ../success/
[xx@xx1 success]$ ls -ld
drwxrwxrwx 2 550 its 4096 Jul 11 12:22 .
however when I try to do it using utl_file
I get an error
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
v_direc constant varchar2(80) := 'IN_DIR';
v_direc2 constant varchar2(80) := 'SUCCESS_DIR';
v_file := 'file1.xml';
utl_file.frename(v_direc, v_file, v_direc2, v_file);
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
What is utl_file.frename doing that is stopping this working unless the group permission is set.
(126.96.36.199, redhat 2.1)
Last edited by davey23uk; 07-11-2005 at 09:31 AM.
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.
they are all on the same disk, the permisions on the both directories are 777.
It works when the oracle user has write access to the file, doesnt work when the oralce user doesnt have write permission to the file.
Just want to know what oracle needs write permission when it can happily do it from the command line without it
The oracle user is doing the move, not "550" (assuming oracle is not 550).
Originally Posted by davey23uk
no its not, but its a member of that its group - im just confused why I can do it from the command line but not from utl_file
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.
use the CREATE DIRECTORY feature instead of UTL_FILE_DIR for directory access verification.
yes the the setup is fine, if i add group write permissions everything works fine.
This article indicates that it may have to do with the permissions that are 'granted' via the programs that are being exectued.
"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
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.
Click Here to Expand Forum to Full Width