We're having a problem where on (random) occasion a particular file cannot be created, nor deleted. The file does not exist, any attempt to write to it (even as root at the console) results in a "Permission Denied" message.

An automated process has sftp'd the files to this location like this:

under "/dirX/" file001 thru file999 have been transferred with the exception of file666. File 666 resulted resulted in a permission denied error.

  1. the file doesn't exist
  2. (as root) touch /dirX/file666 ->permission denied

we tried this:

mv /dirX /dirSomething
touch /dirSomething/file666 # OK!
mv /dirSomething /dirX #OK!
cat /dirX/file666 #OK!
rm /dirX/file666 #permission denied
mv /dirX /dirSomethingElse #permission denied.

Our support staff brought the system offline and ran fsck which did find and correct 1 error. This didn't solve the problem nor prevent it from happening again.

It's as if the file system hates that particular name and refuses to do anything with it.

What could cause such an issue?

Edit: Abbreviated truss output:

pathconf("file666", 20)               = 1
acl("file666", GETACLCNT, 0, 0x00000000) = 4
stat64("file666", 0xFFBFEC90)         = 0
acl("file666", GETACL, 4, 0x00027928) = 4
lstat64("otherfile666", 0x00026630) Err#2 ENOENT
rename("file666", "otherfile666")           Err#13 EACCES
fstat64(2, 0xFFBFDF10)        = 0
mvwrite(2, " m v", 2)         = 2
: cannot rename write(2, " :   c a n n o t   r e n".., 16)      = 16
file666write(2, " f i l e 6 6 6".., 17)     = 17
 to write(2, "   t o  ", 4)           = 4
otherfile666write(2, " b k . t x t", 6)     = 6
: write(2, " :  ", 2)         = 2
Permission deniedwrite(2, " P e r m i s s i o n   d".., 17)     = 17

ls -hal output

FJSV>host{root}: ls -hal *
-rw-r--r--   1 a817768  nologin      34K Jun 26 14:56 file666

3 Answers 3


The Solaris ppriv command can be used to debug Permission Denied issues. Try this:

ppriv -e -D touch /dirX/file666
  • Accepting this answer because my boss said this worked. I'll try to fill in details of the solution later.
    – hometoast
    Aug 25, 2009 at 19:56

What are the results from:

ls -hal /dirX/file666
lsattr /dirX/file666

Are there any permissions or attributes on this file? My first though, maybe the +i immutable flag was set on it.

Also you can use 'strace' to find out what is giving the permission denied error if it is something not obvious - 'strace rm /dirX/file666'

Also, when they ran fsck, did they run it with bad block checking? (-c)

  • It's on the production system so I'll get someone to check the output of those. But initially, the file won't/doesn't exist, so ls would report nothing.
    – hometoast
    Jun 29, 2009 at 19:01
  • I just realized my reply is linux specific, but there should be similar commands on Solaris (I haven't used Solaris in 11 years!) Jun 29, 2009 at 19:04

For what it's worth, "permission denied" (EACCES) while renaming or deleting a file points to a problem updating the directory, rather than a problem with the file itself. This is a long shot, but you might try deleting and recreating the directory.

This line:

mv /dirX /dirSomethingElse #permission denied.

if it's accurate, also points to a problem with the root directory. I'd be inclined to rerun fsck and/or a surface analysis of the drive, then redo your tests. Randomness like this suggests filesystem corruption or a bad disk block.

  • And I'm inclined to agree. But we did run fsck and also tried the directory many times. This happens randomly with random filename. The dirname is a unit-of-work-number and the files are uniquely named images. Also the FS is hosted on a EMC DMX SAN system - so HDD corruption should be REAL low.
    – hometoast
    Jun 30, 2009 at 2:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .