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

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.

Cheers

(9.2.0.5, redhat 2.1)

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.

John

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

Quote:

---

Originally Posted by davey23uk

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

---

The oracle user is doing the move, not "550" (assuming oracle is not 550).

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.


--------------------------------------------------------------------------------
Note:
use the CREATE DIRECTORY feature instead of UTL_FILE_DIR for directory access verification.
"

http://download-west.oracle.com/docs...le.htm#1002684

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.

http://www.hccfl.edu/pollock/AUnix1/FilePermissions.htm

"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.