sh: /var/tmp/sh7877.13: Cannot create the specified file.

[Dennis Handly]

>chown / chmod 777 was run by mistake on /usr. It was later fixed by going to single user.

Did you use the super dangerous chmod -R?  Fixed how?  Did you try "swverify -F"?

>[oracle@recoverednode][oracle]>ll -d /var/tmp
drwxrwxr-t 8 root root 8192 Nov 15 19:22 /var/tmp

The way to fix this is to use: chmod o+w /var/tmp

Don't ever be tempted to use use obsolete octal numbers, always use symbolic form.

># chmod 777 /var/tmp

This isn't the right fix, it removes the "t" (sticky) bit.  Now you have to use: chmod u+t /var/tmp

>if that file already exists in that directory and is owned by someone else, then a new user won't be able to create a new one.

I had that happen with rogue here docs, filled it up with tens of thousands of sh*.* files.

>unless that "t" is actually significant.

Only for security enforcement.

>pro3$ chmod 1777 fred

Or chmod a=rwx,u+t fred

[Torsten.]

IMHO the recovered system is not recovered and at risk. restoring ignite backup would be s safe option.

[Steven Schweda]

> Don't ever be tempted to use use obsolete octal numbers, always use
> symbolic form.

   Because ...?

> IMHO the recovered system is not recovered and at risk.

   Clearly, some damage remains.

>  restoring ignite backup would be [a] safe option.

   Comparing the affected files with equivalent files on an undamaged
system should help.  "swverify -F" should help.  "swverify" can't fix
non-OS files (about which it knows nothing), comparison works only for
common files, and backup works only for files older than the backup.
All of which serves as a reminder of why it pays to give the "root"
password to only those who have some idea of how much they don't know.

      https://en.wikipedia.org/wiki/There_are_known_knowns

[Dennis Handly]

>Because ?

Because of problems like this.  I.e. using "chmod 777 -R".  If you used "chmod a+w -R", you would only have security problems.