Hosts File Permission Denied on Mac

"Permission denied." These two words have frustrated countless developers trying to edit their hosts file on Mac. You know what you want to do, you know the command, but macOS won't let you. Sound familiar?

How to fix "Permission denied" on the Mac hosts file

The "Permission denied" error means you tried to save /etc/hosts without administrator rights. Edit it with sudo, run sudo nano /etc/hosts in Terminal and enter your admin password, or open your text editor as administrator. If sudo still fails, confirm your macOS account is an administrator and that the file is not locked or protected by a security tool.

This comprehensive guide will walk you through every possible permission issue you might encounter when editing the hosts file on macOS. We'll cover sudo access, System Integrity Protection, file ownership, permissions, and even disk-level issues. By the end, you'll understand not just how to fix permission problems, but why they occur in the first place.

Understanding macOS file permissions

Before diving into fixes, it's essential to understand how macOS handles file permissions. The hosts file at /etc/hosts is a system file, which means it has special protection.

Why hosts file requires special permissions

The hosts file controls DNS resolution for your entire system. If any user could modify it, malicious software could redirect your traffic. macOS protects it by:

1. Ownership: Owned by root (superuser)
2. Permissions: Readable by all, writable only by owner
3. Location: In /etc directory (system configuration)

Standard hosts file permissions

The hosts file should have these permissions:

• Owner: root
• Group: wheel
• Permissions: 644 (rw-r--r--)
• Owner (root): read + write
• Group (wheel): read only
• Others: read only

Error #1: "Permission denied" without sudo

This is the most common error. You tried to edit the file without administrator privileges.

The error

$ nano /etc/hosts
# Error: Permission denied

Or:

$ echo "127.0.0.1 test.local" >> /etc/hosts
# zsh: permission denied: /etc/hosts

Why it happens

You're trying to modify a system file as a regular user. macOS blocks this for security.

Solution: Use sudo

Prefix your command with sudo:

sudo nano /etc/hosts

Or:

echo "127.0.0.1 test.local" | sudo tee -a /etc/hosts

How sudo works

sudo (superuser do) temporarily elevates your privileges to root level. When you run sudo, macOS:

1. Prompts for your password
2. Verifies you have admin rights
3. Grants temporary root access
4. Logs the action for security

Entering sudo password

When prompted, enter your user account password (the one you use to log into your Mac), not a root password. Nothing appears as you type, this is normal security behavior.

Error #2: "User is not in the sudoers file"

This error means your account doesn't have administrator privileges.

The error

$ sudo nano /etc/hosts
# [yourname] is not in the sudoers file. This incident will be reported.

Why it happens

Your user account doesn't have administrator rights. This can happen if:

• Account was created as a standard user
• Admin rights were removed
• Corporate/managed Mac with restricted access

Solution: Get administrator privileges

If you're the Mac owner:

1. Go to System Preferences > Users & Groups
2. Click the lock icon (enter admin password)
3. Select your account
4. Check "Allow user to administer this computer"
5. Log out and back in

If you're on a managed Mac:

Contact your IT administrator. They need to grant you admin rights or edit the hosts file for you.

Verify admin status:

groups

You should see admin and staff in the output.

Error #3: "Operation not permitted" (SIP-related)

System Integrity Protection (SIP) is macOS's security feature that protects system files. While it shouldn't prevent editing /etc/hosts, misconfigurations can cause issues.

The error

$ sudo nano /etc/hosts
# Operation not permitted

Even with sudo, the operation fails.

Check SIP status

csrutil status

You'll see one of:

• System Integrity Protection status: enabled. (normal)
• System Integrity Protection status: disabled. (SIP is off)

When SIP interferes

SIP shouldn't block /etc/hosts editing. However, it might interfere if:

• You're in Recovery Mode
• SIP was partially disabled
• System files are corrupted

Solution: Verify SIP isn't the issue

Normal operation (SIP enabled):

If SIP is enabled, it's not blocking hosts file edits. The issue is elsewhere (check other sections).

If you need to disable SIP (not recommended):

1. Boot into Recovery Mode (hold Cmd+R during startup)
2. Open Terminal
3. Run: csrutil disable
4. Reboot
5. Edit hosts file
6. Re-enable SIP: Boot to Recovery, run csrutil enable

Warning: Disabling SIP reduces system security. Only do this if absolutely necessary and re-enable immediately.

Error #4: Incorrect file ownership

The hosts file must be owned by root:wheel. If ownership is wrong, edits might fail.

Check ownership

ls -la /etc/hosts

Should show:

-rw-r--r-- 1 root wheel 1234 Feb 6 10:30 /etc/hosts

The root wheel part indicates ownership.

Wrong ownership example

-rw-r--r-- 1 alex staff 1234 Feb 6 10:30 /etc/hosts

This shows the file is owned by user alex instead of root.

Fix ownership

sudo chown root:wheel /etc/hosts

Verify:

ls -la /etc/hosts

Should now show root wheel.

Error #5: Incorrect file permissions

Even with correct ownership, wrong permissions can prevent editing.

Check permissions

ls -la /etc/hosts

Look at the permission string (first 10 characters):

-rw-r--r--

Broken down:

• -: Regular file (not directory)
• rw-: Owner (root) can read and write
• r--: Group (wheel) can read only
• r--: Others can read only

Common wrong permissions

Too restrictive:

-r-------- 1 root wheel /etc/hosts

Only root can read, this might cause issues.

Too permissive:

-rw-rw-rw- 1 root wheel /etc/hosts

Everyone can write, security risk!

Wrong format:

-rwxr-xr-x 1 root wheel /etc/hosts

Executable bit set, not needed for hosts file.

Fix permissions

Set correct permissions:

sudo chmod 644 /etc/hosts

What 644 means:

• 6 (owner): read (4) + write (2) = 6
• 4 (group): read (4) only
• 4 (others): read (4) only

Verify permissions

ls -la /etc/hosts

Should show: -rw-r--r--

Error #6: Disk permissions issues

Sometimes the problem isn't with the file itself, but with the disk's permissions system.

Check disk permissions

diskutil verifyPermissions /

This checks if system file permissions are correct.

Repair disk permissions

sudo diskutil repairPermissions /

Note: On macOS El Capitan and later, repairPermissions is deprecated. Use First Aid in Disk Utility instead:

1. Open Disk Utility
2. Select your disk
3. Click First Aid
4. Click Run

Alternative: Reset NVRAM

Sometimes permission issues are cached in NVRAM:

1. Shut down your Mac
2. Turn it on and immediately hold: Option + Command + P + R
3. Hold for about 20 seconds
4. Release and let Mac boot normally

Error #7: Read-only file system

In rare cases, the file system might be mounted read-only (usually after a crash or in Recovery Mode).

Check file system status

mount | grep " / "

Should show something like:

/dev/disk1s1 on / (apfs, local, journaled)

If you see read-only, that's the problem.

Solution

If in normal boot:

1. Restart your Mac
2. If problem persists, run First Aid in Disk Utility

If in Recovery Mode:

The file system is read-only by design. You can still edit hosts file, but changes might not persist. Boot normally to make permanent changes.

Error #8: Corporate/managed Mac restrictions

On managed Macs, additional restrictions might prevent hosts file editing.

Common restrictions

• MDM profiles: Mobile Device Management can restrict system file access
• Parental controls: Can limit admin access
• Security policies: Corporate policies might block sudo access

Check for restrictions

profiles -P

Shows installed configuration profiles.

Solutions

Contact IT:

Ask your IT administrator to:

• Grant you admin rights temporarily
• Edit the hosts file for you
• Provide a workaround for your use case

Use alternative methods:

• Local development server configuration
• VPN with custom DNS
• Browser extensions for domain mapping

Complete permission fix checklist

Follow this systematic approach:

Step 1: Verify admin account

groups | grep admin

Should output admin. If not, get admin rights (see Error #2).

Step 2: Check file ownership

ls -la /etc/hosts

Should show root wheel. If not:

sudo chown root:wheel /etc/hosts

Step 3: Check file permissions

Should show -rw-r--r--. If not:

sudo chmod 644 /etc/hosts

Step 4: Verify SIP status

csrutil status

Should be enabled (normal). If disabled and causing issues, consider re-enabling.

Step 5: Test edit with sudo

sudo nano /etc/hosts

If this works, permissions are correct. If not, check error messages.

Step 6: Check disk health

Run First Aid in Disk Utility to check for disk issues.

Prevention: Best practices

Use sudo correctly

Always use sudo for system file edits:

sudo nano /etc/hosts # ✅ Correct
nano /etc/hosts # ❌ Wrong - permission denied

Backup before editing

sudo cp /etc/hosts /etc/hosts.backup.$(date +%Y%m%d)

Use GUI tools

GUI applications like ToggleHosts handle permissions automatically:

• Request admin access when needed
• Verify permissions before editing
• Fix permissions if incorrect
• No need to remember sudo commands

Verify after changes

After editing, verify the file:

ls -la /etc/hosts
cat /etc/hosts

Advanced: Understanding permission numbers

Octal notation

Permissions are often shown in octal (base 8):

• 0: No permissions
• 1: Execute only
• 2: Write only
• 3: Write + Execute (2+1)
• 4: Read only
• 5: Read + Execute (4+1)
• 6: Read + Write (4+2)
• 7: Read + Write + Execute (4+2+1)

Common permission values

• 644: Owner read+write, others read (standard for hosts file)
• 755: Owner read+write+execute, others read+execute (directories)
• 600: Owner read+write only (private files)
• 777: Everyone can do everything (security risk!)

Setting permissions

chmod 644 /etc/hosts # Numeric
chmod u=rw,go=r /etc/hosts # Symbolic

Troubleshooting specific scenarios

Scenario 1: "Permission denied" but I'm admin

Check:

1. Are you using sudo?
2. Is your password correct?
3. Check admin status: groups | grep admin
4. Try: sudo -v to refresh sudo timestamp

Scenario 2: Can read but can't write

Check:

1. File permissions: ls -la /etc/hosts
2. Should be -rw-r--r-- (644)
3. Fix: sudo chmod 644 /etc/hosts

Scenario 3: Works in Terminal but not in GUI editor

Cause: GUI editor might not request admin access properly.

Solution: Use Terminal with sudo, or use a GUI tool that handles permissions correctly.

Scenario 4: Permission denied after macOS update

Cause: macOS updates sometimes reset file permissions.

Solution: Re-apply correct permissions:

sudo chown root:wheel /etc/hosts
sudo chmod 644 /etc/hosts

Security considerations

Why permissions matter

Correct permissions protect your system:

• Prevents malware: Malicious software can't modify hosts file
• Prevents accidents: Regular users can't break DNS resolution
• Audit trail: sudo logs all privileged actions

Don't disable security

Avoid:

• Disabling SIP permanently
• Making hosts file world-writable
• Running as root user
• Sharing admin passwords

Conclusion

Permission denied errors when editing the hosts file are frustrating, but they're almost always solvable. The most common issues are forgetting sudo, incorrect file permissions, or account not having admin rights.

Remember the golden rule: Always use sudo for system file edits, verify your admin status, and check file permissions if issues persist.

For the easiest experience, consider using a GUI tool like ToggleHosts (4.99 €) that handles all permission complexity automatically. It requests admin access when needed, verifies permissions, and ensures your edits succeed without manual troubleshooting.

If you're still experiencing issues after trying these solutions, check our hosts file troubleshooting guide, learn how to edit hosts file on Mac, or read how to edit the hosts file as administrator on Windows, Mac and Linux.

Sources and further reading

• Terminal User Guide (Apple Support)
• The hosts file explained (Wikipedia)
• hosts(5) manual page (man7.org)