AC-00002: Error: Unable to create log file

Makarand was doing a Fresh R12 install. The install was successful on the Database Node and Primary Application Node. On Primary Application node only 'Batch Processing Services' are enabled.

However while installing on the additonal application node the rapidwiz was giving errors

'AC-00002: Error: Unable to create log file - $INST_TOP/$CONTEXT_NAME/logs/08031631.log
Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: AC-00002: Unable to create log file -
$INST_TOP/$CONTEXT_NAME/logs/08031631.log

Makarand had tried installing multiple times but every time it failed with the same message

The truss of the rapidwiz process showed this:

/40: open64("$INST_TOP/$CONTEXT_NAME/logs/08200953.log",
O_WRONLY|O_APPEND|O_CREAT, 0666) Err#13 EACCES


Here’s the reason for the failure:

apps11i is the app tier and you are trying to write to an NFS mount. If you access an NFS mount from a server other than its origin, the root user of the application server is treated as nobody user. I verified this by touching a file while logged in as root:

-rw-r--r-- 1 nobody nobody 0 Aug 20 10:59 abc

This happens if the NFS share is shared without root= in the NFS mount command.

An examination of the /etc/dfs/dfstab file revealed that:

share -F nfs -o rw=visionerp.justanexample.com,root=visionerp.justanexample.com /gpshpc76/custom
share -F nfs -o rw=erpr12.justanexample.com,root=erpr12.justanexample.com /erpr12/erpapp
share -F nfs -o rw=erp11i.justanexample.com,root=erp11i.justanexample.com /erp11i/erpapp

If you compare the last line with a line for other instances it clearly shows that the application server has no read write rights and no root equivalence. I corrected this by executing this command:

share -F nfs -o rw=apps11i.justanexample.com,root=apps11i.justanexample.com /arpsysd1/erpapp

I also corrected it in the /etc/dfs/dfstab.

After this we retried the rapidwiz and it worked.

root has no powers on NFS drive

In our shared application file system instance, where a SAN mount on database server is NFS mounted on 4 application servers, we were installing Olite.  Olite requires running root.sh script. But the root.sh always gave permission denied whenever we ran it from the application tier. This was happening because the uid and gid of root did not match on the application server and the database server.  Application Server was installed as Solaris 10 where root's gid is 0.  DB server was upgraded from Solaris 8 to Solaris 10.  In Solaris 8 the root user's gid is 1.  After changing the root user's gid to 0, the script ran fine.

NFS does NOT behave the same as a local filesystem, especially for root! NFS is a very non-secure method to share filesystems and unless the NFS server exports the filesystem with a special root option, the root user on the local computer is nobody (literally!). That's why there is a 'nobody' user and it has a user ID of -2. This user has NO special privileges. Th1e reason is fairly obvious. If a server were to blindly export filesystems to any computer on the network (with root=root privileges), then the contents of the filesystem could NEVER be trusted as any machine could trash any file or directory.

So even if you were root on your local box, chown will return EPERM (errno 1) because the NFS filesystem says you are nobody and therefore not the file's owner. /etc/exports on the NFS server can allow root access but one should be very careful to restrict root privileges for the above mentioned reasons.