Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I just discovered that nano, KWrite and Kate all silently overwrite read-only files when editing as root -- even if the file permissions are 400 (-r--------). It also doesn't matter if root is the owner or not.

Is this behavior configurable somewhere? (I don't see it mentioned in the nano manual here, for example, but I'm hoping there is a way to fix this at the system level.) Additionally, the behavior isn't limited to just a specific editor, as my testing with nano, Kate and KWrite show.

Alternatively, what are my other options? Is there a different set of (standard linux) permissions that would change this behavior? I know root can delete any files, but I was expecting at least a warning when editing/changing a read-only file.

I'm running Kubuntu 12.04 with regular linux file permissions (i.e., no SELinux or ACLs). Also using btrfs if that matters.

share|improve this question
up vote 2 down vote accepted

Yes, there is a different set of linux attributes that would prevent the file from being modified. Set the file as immutable with the command chattr +i filename.

Please see for details.

share|improve this answer

It depends on the editor.

It's entirely possible for a text editor to check the permissions on the file, and refuse to write to it if it doesn't have write permissions for either owner, group, or others. Just because it can write to a file (because it's running as root), that doesn't mean it has to.

I just tried this with vim 7.3 on Ubuntu, and it actually does do this. If I edit a file as root, it sets it to readonly mode. (I can still write to it by using :w! rather than :w.) GNU Emacs 23.2.1 behaves similarly.

nano, as you observe, doesn't do this; I haven't tried other editors. But nano -v edits a file in "view" (read-only) mode. It shouldn't be too difficult to write a wrapper that checks the permissions on a file and invokes either nano or nano -v, depending on whether it should be writable. (Note that you'd need to use something other than the [ -w filename ] test; if you're root, it returns true for a file with 400 permissions.)


Here's a nano wrapper I just threw together in Perl. It doesn't accept any arguments other than a single file name, which is mandatory (and the file must already exist).


use strict;
use warnings;

die "Usage: $0 file\n" if scalar @ARGV != 1;
my $file = $ARGV[0];
die "$file does not exist\n" if not -e $file;

my @stat = stat $file;
die "stat $file: $!\n" if not @stat;

my $mode = $stat[2];

my @command = qw(nano);
if (($mode & 0222) == 0) {
    push @command, '-v';
push @command, $file;

# print "\$ @command\n";
exec @command;

Rather than checking whether the file is writable, it retrieves its mode bits and directly checks whether any of the write bits are set. It seems to work with the very cursory testing I did. Use this at your own risk. It should be easy to adapt to other editors.

BTW, I never use nano myself. It seems that when you quit, it asks whether you want to save the modified buffer and prompts for the file to save it to, even if the file is writable. At least in its default mode, it seems to me that it would be difficult to accidentally clobber a file. I suppose it's easier if you set some options for "expert" use.

share|improve this answer
thanks for the ideas. I'll have a look at a few editors. I'd appreciate a few more details on the nano wrapper too, if you can. – MountainX Mar 27 '12 at 0:15
Thanks for your excellent answer. Sorry it took me a few weeks to accept it. – MountainX Jun 28 '12 at 2:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.