Can't get ownership to "hosts" file to edit it!

Tried everything I could understand without another day searching the internet and Google as well.

I need to edit the etc/hosts file.
Unable to take ownership of “hosts” file, ergo unable to edit it.

I tried to take ownership, but the online explanations assume we all have a few years of Linux geekinese under our belts. When I see:
search results like “chown name filename”
I see “chown” as the command, then “name” and I ask, whose name? and “filename” I get.
I tried the name “Pure-1” which is the name Pure was set up under, is login, and I thought was owner, but Pure says no.

~Can’t edit it not permitted.
~chown most online suggestions fails with "changing ownership of ‘hosts’ : Operation not permitted".

In Pure, is there a way to bypass the paranoid rent-a-cop at every turn?

I hope everything isn’t command line driven.


To find out your user name that the system actually uses, issue this command:


Then you can do

chown username filename

But I would recommend to not leave it owned by your user, because it’s controlling an important, security-relevant part of the OS, and regular programs shouldn’t have access to it. So better check the previous owner first:

ls -lG /etc/hosts

It will probably be root, represented by:

-rw-r--r--. 1 root 119 Apr  7  2020 /etc/hosts

Then you can chown it back to root.

Just curious, why do you need to change /etc/hosts? I’ve had this need maybe twice in my life.


Some of ‘the team’ (people I work with) need to access a web site before it is redirected, or propagated, or while waiting for the occasional lackadaisical Registrar. We use the host file to access the front and back-ends, Plex or cPane etcetera.

For others that might find this, it’s also how we can edit, preview, test an so on without the site even being available yet or not on any DNS.

Many hosts have dropped the H—:// address/ ~ domainName - this works around that too. Also, it makes it much easier for everyone to exchange changes, edits and the such.

Some domains can sit pointed at the Registrar until we are ready, then we just change the nameservers.


Why do you need to own /etc/hosts to edit it? sudo nano /etc/hosts should be enough.

If you need to get ownership of a file owned by root, you need to use sudo chown.

The reason chown fails is because you need ownership of a file to change its ownership. The reason the ownership and permissions system exists is because some files need to be restricted so that only the right users can edit, view, or execute them. If any user could tell the system, “ok I know I’m not supposed to be able to edit this file, but I want to” and get access to it, there would be no point to the permissions system.

One implication of you owning a file is that any process running under your account also has access to that file. This is the default behavior for processes. So if you take ownership of /etc/hosts and have a malicious process running in the background, it now has access to your /etc/hosts file and can edit it too. This is why its ownership is with root in the first place.


sudo gedit /etc/hosts if you don’t want to use the command line.


No, don’t run graphical applications as root, unless there is absolutely no way you can avoid it.

It will cause permissions issues with files in your home folder where files that should be owned by you become owned by root. In extreme cases this can prevent you from logging in at all.

It’s a security nightmare.

That’s not to say there’s never a time when you have to bite the bullet and do this, e.g. for running trusted closed-source software with an installer that insists on root access, but editing text files is definitely not the time to do it.


To be extra nitpicky, there’s nothing specific to graphical applications that trashes your home directory :slight_smile: It can be done with terminal based ones too.

can cause, same as any other program, as @dcz said.

This also applies to “security nightmare.”

I’m sure you make a good point, but “YOUR WORLD WILL END” isn’t the proper justification.

1 Like

While the point about any program modifying config files in your home folder is valid, CLI editors tend to rely on those files far less than GUI editors. Nano, for example, can be configured with ~/.nanorc, but it doesn’t generate this file by default and it won’t touch it if you do run nano as root. This is something that may or may not be an issue depending on which editor in particular you use, and could be managed in theory if you knew for sure you weren’t going to accidentally set root permissions silently on some files that weren’t supposed to have those permissions.

That same reasoning doesn’t apply to the security threat though; GUI applications are unique in this. I’ll refer to the bugzilla comment I linked:

By running GUI applications as an admin user you’re literally running millions of lines of code that have not been audited properly to run under elevated privileges; you’re also running code that will touch files inside your $HOME and may change their ownership on the file system; connect, via IPC, to even more running code, etc.

I’m not acting like your world will end if you do this. I have to do it sometimes myself, and like I said before, sometimes there are valid reasons to run a GUI application as root. Editing text is not one of them.

Sweeping generalizations like these detract from the good points, and is why I didn’t pay much attention to the bugzilla comment you linked. I’m happy to hear good points, but not sensationalized presumptions.

I’m not sure how this is a “sweeping generalization,” the GTK and Qt codebases are huge. I haven’t checked myself to see if they’re “literally… millions of lines of code” but it wouldn’t surprise me if they were up there. I think at least hundreds of thousands of those being executed for any given GUI program, including all of the libraries needed to make it work, isn’t an unreasonable estimate.

Its not talking about the codebases at large, its talking about “a GUI application.” At least, its written that way.

At any rate, I take your point, in a general sense.

1 Like

Well, that certainly went sideways.

My response was already above your question. But I had tried your suggestion, and others as well. And after a bit of fingering the Internet, and more reading here, somehow - perhaps by the grace of the Matrix, I was able to open and edit the file. All I have to do noq, is set it so that whatever, or whomever should have control back again.

For the sake of searchers, I do this to edit the file and access any site that has not propagated.

Usng a ascii editor, go to bottom and
enter the ip address - this can even be a site on a shared Host,
follow it with the domain name as recorded in Plex or cPanel.

# the pound/hash/number can be used to add a comment (add a few spaces) domainname.ext
# end with another comment if you wish.
# NO http or https or :// just domain name and ext.
(Sorry - but this little editor won’t format as ‘code’ while hash-tags are in it.)

Now your browser will go to the ISP/domainname.ext


I’m not seeing where you said you tried running an editor with sudo. There’s no need to take ownership of the file and owning that file in particular at any point is a security risk.

Use sudoedit if using a regular editor doesn’t work. This is actually preferable since it’s designed specifically for this use case.

You can get code formatting in Markdown editors including pound signs by using three grave accents (```) on the line before and the line after your code:

# a bash-style comment
int a;  // a c-style comment

The editor will try to auto-detect the language in the code block and apply syntax highlighting accordingly, but you can specify the language after the top three grave accents to ensure you get correct highlighting: e.g. ```C gives

# a bash-style comment
int a;  // a c-style comment

Four spaces before each line works too but only does monospace formatting, no syntax highlighting

# a bash-style comment
int a; // a c-style comment

This needs to be emphasized.

As a general rule across all Linux system files … unless you really really know what you are doing, don’t change the ownership or permissions.

A very few components will sanity check the ownership and permissions, and complain if a security risk has been introduced by virtue of lax file access. Most will not make such a check. I guess that is consistent with the Linux philosophy - it is “open” to you to break your security - but …

Conversely, removing file access will also quietly break things in some cases.

In summary, sudo vi /etc/hosts

job done

and don’t even think about changing ownership or permissions.

An alternative approach, if you run your own DNS server, is just to add domain names temporarily to the config of your DNS server. That has the advantage of making the missing domain name available to the whole site until such time as the global DNS is up to date.

if you use vi or vim in the terminal emulator then (once you are in the program) you have :

  1. write your changes to disk > :w
  2. quit the program > :q

vi/vim is a powerfull terminal emulator program (CLI) but it might be more CONVENIENT for you to use nano since it has on screen indication for you if you venture in …

on the same note if you feel like experimenting/learning you can use Emacs but we’re getting into gods territory here :wink: :joy: