I have a small program and I want to ensure that it works on both write protected files and un-write protected files. So, instead of using echo $text > $file or echo $text >> $file, I am instead forced to use echo $text | sudo tee $file and echo $text | sudo tee --append $file, respectively. When I use sudo tee, even if I change the permissions, whenever I use rm on the file, it prompts me like so:

$ ls
someFile writeProtectedFile
$ rm someFile
$ ls
$ rm writeProtectedFile
rm remove write-protected regular file 'writeProtectedFile'? yes
$ ls

I then poked around on the web, looking for possible solutions to my dilemma. There were only two out there that I could find: incorrect permissions, or a changed set of permissions. I knew the permissions case to be incorrect, because I could easily change the permissions by running sudo chmod xxx filename, which would result in a successful permissions change. I assumed then that there was a problem with the file attributes, so I ran lsattr on the file and it would output -------------e--, same as every other file in the directory.


The reason I was using tee was to echo text to write protected files, but as a side effect it also write protected regular files... My goal was to, in effect, do something like sudo echo "whatever" >> /etc/someFile, which does not work, so I found a solution in echo "whatever" | sudo tee /etc/someFile.

  • 2
    Why would you be "forced" to use sudo tee? That just makes the file owned by root and creates a problem where there was none. What does your program actually do? We can't answer this because you 1) don't tell us what the real problem is, what the program is doing; 2) You say chmod xxx but don't give us the real xxx you used. It sounds like you just want rm -f but I can't understand the question well enough to be sure. – terdon Jul 22 '15 at 12:52
  • You shouldn't really be writing in /etc unless you understand the implications. Write to somewhere you have access and you can avoid the mess with tee – roaima Jul 22 '15 at 20:00
  • @roaima It was an example of what the program's capabilities are... A practical example would be writing to /etc/apt/sources.list on a Debian/Debian based distro,.. Another good example is editing the environment file, the bashrc, or your X11 configs... – Interesting... Jul 23 '15 at 12:18

The command tee, when passed a non-existing file as parameter, will create that file before writing the output to it. By prepending that command with sudo, you are asking your shell to run the tee command as root. The consequence is that the file created by tee is owned by the user starting the command: root, and is therefore read-only for other users. You can see this by yourself if you run ls -l and look at the user and group columns.

$ rm -f writeProtectedFile # Removing the file in case it already exists
$ echo $text | sudo tee writeProtectedFile
$ ls -l
total 4
-rw-r--r-- 1 root root 9 22.07.2015 14:26 writeProtectedFile

There are several options to overcome this:

  • Create the file as a standard user before asking tee to write to it. tee will then either truncate or simply --append to it, without changing its ownership:

    $ touch writeProtectedFile # creates the file as standard user
    $ echo $text | sudo tee writeProtectedFile
    $ rm writeProtectedFile
  • Change the ownership of the file before trying to delete it:

    $ echo $text | sudo tee writeProtectedFile
    $ sudo chown $(whoami) writeProtectedFile # `whoami` returns the current user name
    $ rm writeProtectedFile
  • Tell rm to ignore the fact that the file is write-protected, using -f, --force:

    $ echo $text | sudo tee writeProtectedFile
    $ rm --force writeProtectedFile
| improve this answer | |

If the file you are creating is in /etc, you won't be allowed to remove it anyway. That is to say, if we are regular user, and we do this:

$ sudo touch /etc/foobar
$ rm /etc/foobar

The touch will work, but the rm will fail, because we do not have write permissions to the /etc directory.

At the operating system kernel level, write permissions on a file are irrelevant in regard to its deletion (or rename/move). The prompt about deleting a write-protected file is just an application-level feature cooked into the rm program. When you say y to the prompt, rm makes a call to the operating system (most likely the unlink function) to blow the file away, without changing its permissions first. (Note that since you don't own the file, changing its permissions is not even permitted!)

However, anything that changes the contents of a directory (like adding or removing a file) requires write permissions for the directory.

So, in summary, the thing to do here is:

$ sudo rm -f /etc/foobar

The sudo to be root, so as to have the needed write access to /etc and the -f to suppress the prompt out of rm.

| improve this answer | |

You say that your goal is the equivalent of

sudo echo "whatever" >> /etc/someFile

but with the redirection >> also given root privileges. Have you considered this alternative

sudo sh -c "echo 'whatever' >> /etc/someFile"

I have used double quotes around the expression so that shell variables (if any) are interpolated before sudo sh is called, rather than trying to delay the evaluation for the sh. This is mainly because sudo pares down the environment so some variables may not exist and others may have been reset. Fo example $$ will present the caller's pid rather than that of the sh.

| improve this answer | |
  • This is not an answer; it's just a different way of getting the same problem — the newly created file will still be owned by "root". – Scott Sep 17 '15 at 18:59
  • @Scott I don't see anywhere in the question a requirement that specifies ownership. Having just re-read the question and my answer I'm puzzled why you say it's not a (valid) answer – roaima Sep 17 '15 at 20:19
  • (1) Your answer seems to provide a different way of doing what the OP is already doing.  The OP didn’t ask for a different way of doing what he/she is already doing; the question asks how to solve a problem (which your answer doesn’t address).  (2) The question says (paraphrased) «When I use echo $text | sudo tee $file … as a side effect, when it makes (creates) a file, it also write protects regular files, … and when I use rm on the file, it prompts me remove write-protected regular file …?»  … (Cont’d) – Scott Sep 18 '15 at 1:00
  • (Cont’d) …  While the question is unclear (e.g., there’s no ls -l output), Emeric has come up with a plausible explanation — when the user creates a file with sudo tee, it is owned by root, and so he can’t subsequently modify it without using sudo again (or, at least, needing to answer the prompt from rm).  Hence my comment — if the user’s script uses your command to append to a file that doesn’t exist, it will be created owned by root, and the user won’t have write access to it. – Scott Sep 18 '15 at 1:02
  • @scott appending or overwriting a file that already exists does not change its permissions or ownership. (Perhaps you'd like to try my suggestion before claiming it won't work?) – roaima Sep 18 '15 at 6:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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