I have a ReadyNAS box named "storage" that I believe is based on Debian. I can ssh into it as root. I'm trying to reconfigure the webserver, but I'm running into a file permissions problem that I just don't understand. I can't do anything with /etc/frontview/apache/apache.pem even as root! It doesn't appear to have any special permissions compared to other files in the same directory and I can work with those.

storage:~# whoami 
storage:~# cd /etc/frontview/apache/   
storage:/etc/frontview/apache# ls -lah apache.pem*         
-rw-------    1 admin    admin        4.0k Jul 10  2013 apache.pem
-rw-------    1 admin    admin        4.0k Jun  9 05:57 apache.pem.2017-02-04
-rw-------    1 admin    admin        1.5k Jun  9 05:57 apache.pem.orig
storage:/etc/frontview/apache# touch apache.pem            
touch: creating `apache.pem': Permission denied
storage:/etc/frontview/apache# touch apache.pem.2017-02-04 
storage:/etc/frontview/apache# rm -f apache.pem
rm: cannot unlink `apache.pem': Operation not permitted

What is so special about this file that it can't be touched? I can't delete it. I can't change the permissions on it. I can't change the owner of it.

The directory seems to be fine. It has space left, it isn't mounted read-only. In fact I can edit other files in the same directory.

# ls -ld /etc/frontview/apache
drwxr-xr-x    8 admin    admin        4096 Jun  9 05:44 /etc/frontview/apache
# df /etc/frontview/apache
Filesystem           1k-blocks      Used     Available Use% Mounted on
/dev/hdc1            2015824        504944   1510880   26% /
  • Please also show the output of ls -ld /etc/frontview/apache and df /etc/frontview/apache. Maybe the folder is on a disk space mounted ro?
    – Ned64
    Commented Jun 9, 2017 at 10:09
  • I added that info to the question. It all looks fine to me. In any case, if that were the problem, I wouldn't think I could edit every other file in that directory. Commented Jun 9, 2017 at 10:15
  • @RunCMD I added more specific information to the title and tags. The filesystem is listed as ext3, so ext3 would appear to to support immutable: # mount: /dev/hdc1 on / type ext3 (rw,noatime) Commented Jun 9, 2017 at 10:42
  • 1
    Solaris doesn't support ext3 nor ARM cpu's so that's probably not based on Solaris.
    – alanc
    Commented Jun 9, 2017 at 17:44
  • 1
    I removed Solaris from the question. On further reading it may be based on Debian Etch. Commented Jun 9, 2017 at 18:25

1 Answer 1


I just found the problem. The "immutable" attribute was set on that file. ls doesn't show it. You need a different command to see it:

# lsattr apache.pem*
----i--------- apache.pem
-------------- apache.pem.2017-02-04
-------------- apache.pem.orig

Once I remove the immutable bit, I can edit that file:

# chattr -i apache.pem
# touch apache.pem
  • 1
    I clicked on this question in the "hot network questions" to tell you to check the extended-attributes, but I guess you already did. (IDK why GNU ls doesn't have an option to list attributes. I forget, but maybe even the system call for querying them isn't portable, so it was probably easier just to implement them in a separate utility.) Commented Jun 9, 2017 at 11:20
  • @PeterCordes I agree. I'm sure I set that bit after Googling something like "stop upgrade from overwriting file", but that was years ago and I clearly forgot doing so. It would be nice if ls showed the that bit, or if any of the the other commands I used had more helpful (and specific) error messages about why the permissions were denied. Commented Jun 9, 2017 at 11:28
  • All touch knows is that the system call it attempted (open("apache.pem", O_WRONLY|O_CREAT|..., 0666)) failed with EACCESS. (Use strace -efile touch apache.pem to see the file-related system calls it makes). As the man page for that system call says, there are many possible reasons for EACCESS, and many of them involve parent directories rather than the file itself. Writing code to accurately deduce why a system call returned the error it did would be extremely hard, since different filesystems and OSes are different... Commented Jun 9, 2017 at 11:38
  • Anyway, the universal convention is that when something fails, you look up the error string for the error code (errno) and print that. (Using the C standard library perror function, or equivalent). This is one of the rare cases where that isn't always enough of a hint for the user to quickly find the problem, but most of the time it works very well. (Especially when combined with strace in case there's any doubt about exactly which operation produced the error.) It's not perfect, but it could be much worse (cf. MS Windows where at best you get an error code to google.) Commented Jun 9, 2017 at 11:45
  • Was just playing around with chattr +i, and noticed that rm foo (without -f) prompts: rm: remove write-protected regular file ‘foo’. Because faccessat(AT_FDCWD, "/var/tmp/foo", W_OK) = -1 EACCES (Permission denied). POSIX requires rm to prompt by default before removing write-protected files, and , which is why it checks in the first place. So you would have gotten a big clue faster if you hadn't used rm -f. :/ access(3) asks the kernel to check permissions as if it was really opening for write, so it picks up ACLs and attributes. Commented Jun 9, 2017 at 11:50

You must log in to answer this question.

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