Read only file system mac os big sur

How To Fix Read-Only File System Error When Run Mkdir Command On MacOS

When I run command mkdir in mac os to create a folder, it gives me an error message mkdir: /data: Read-only file system like below. This article will tell you how to fix it.

1. Fix MacOS Read-Only File System Error Steps.

1. Restart macOS, press Command+R to go to macOS utilities window.
2. Click menu item Utilities —> Terminal at top menu bar.
3. Then input command csrutil disable in the popup terminal window. This command will disable the System Integrity Protection.
4. Click Mac Logo —> Restart menu item at the top left corner to restart the macOS.
5. After restart macOS, run the command sudo mount -uw / .
6. Now you can create a directory successfully with the command mkdir .
7. If you want to check whether System Integrity Protection is enabled or disabled, you can run command csrutil status in a terminal.
8. If you want to enable System Integrity Protection, you can restart the macOS and press Command + R to go to the macOS utilities window again to enable it with command csrutil enable in terminal.

2. Resolve Read-only File System Error When Remove Files.

Now we can create a directory in the macOS system. But when I want to remove files, it also shows me below error messages.

To fix this issue, you should run command sudo mount -uw / , after that, you can remove files as you want.

3. Question & Answer.

3.1 Python script meets read-only file system error on macOS.

1. In my python script, I want to use the python os module’s system function to execute a zip command to make a zip file like below.

But when I run the python script, it shows a permission denied error like below.

I have run the command csrutil disable to disable the System Integrity Protection on my macOS, but it still throws the error when I run the python script.

You can try the below steps.1. Run the command fsck -n -f in a macOS terminal. 2. Reboot your macOS. 3. Run the python script file with the root permission.

Источник

How to make root volume writeable in Big Sur?

In Catalina, the root volume could be mounted as read/write by disabling SIP and entering the following command:

This command doesn’t seem to be working under Big Sur:

What should I do now?

Answers

Why do you need to modify the root volume? Given the read-only system volume change we announced last year, and its further evolution this year, that’s something best avoided where possible.

My experience is that most of the common use cases for this are covered by synthetic symlinks (see the synthetic.conf man page).

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = «eskimo» + «1» + «@apple.com»

/etc/synthetic.conf . does not seem to work in Big Sur:

Any further thoughts?

For example i would like to edit /System/Library/LaunchDaemons/tftp.plist file and add -l so i can log tftp to syslog. How you can do it ?

Therefore, I usually use my custom display profile to enable HiDPI support at 2560×1080, which requires access to /System/Library/Displays/Contents/Resources/Overrides/ .

Thanks for the explanation.

Does the equivalent path in /Library work for this? If not, you should definitely file a bug about that. Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = «eskimo» + «1» + «@apple.com»

Try the directions below:

csrutil authenticated-root disable

sudo mount -uw /Volumes/Macintosh\ HD\ 1

sudo /System/Library/Filesystem/apfs.fs/Contents/Resources/apfssystemsnapshot -s «SnapshotName» -v /Volumes/Macintosh\ HD\ 1

sudo /System/Library/Filesystem/apfs.fs/Contents/Resources/apfssystemsnapshot -r «SnapshotName» -v /Volumes/Macintosh\ HD\ 1

Does the equivalent path in /Library work for this? If not, you should definitely file a bug about that. Please post your bug number, just for the record.

FYI, I found most enlightening.

@jichi_zhang, I’m still interested to know if switching to the /Library directory works.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = «eskimo» + «1» + «@apple.com»

I have the same problem as the OP. I got a 1440p screen, the LG 27GL850, on Big Sur Beta 4.
In Catalina, I solved the issue of small UI by using a tool on GitHub called one-key-hidpi. It
makes MacOS think a display is a Retina display, making the scaling settings the Retina monitors get show in the Display options System Preferences for my 1440p.

In Big Sur, the tool no longer works since it doesn’t have access to the root volume anymore.

Like everyone else here, I discovered that you have to as it is said in:

In the mounted directory, I placed necessary file at /System/Library/Displays/Contents/Resources/Overrides/ to add a display option.

By the way, I used this site: wacky.one/blog/macos-hi-dpi/#one-key to generate the file. The site is in Chinese but the file generation part is at the bottom.

When I rebooted the system, I used a tool called RDM (download link is at very bottom of site), which gives you more options for display settings to check if the changes took effect, they didn’t. However, I suspect it was fault on my part. Perhaps I made an error and put the file into the wrong Library. I will try this again tomorrow, I feel like this method is promising.

If anyone is also stuck, feel free to try this method and post your findings here, thanks.

I will also submit a feedback since I’m on the beta, but it likely won’t be addressed any time soon since people have been asking for lower resolution displays to have scaling setting for years now. For now, I will be doing the real work in Catalina.

Источник

Question: Q: Read-only file system external drive

Problem: Two of my external Western Digital drives have suddenly and simultaneously been designated as «read-only file systems.» Consequently, I cannot access them, even with sudo.

Need: I want to mount the drives with read-write access.

This problem renders Time Machine useless and means I have to (occasionally) spend hours manually copying files back and forth using the terminal, as the Finder is never capable of doing so without an error.

At the very least, I would like a workaround to remove whatever marker the OS uses to designate the drives as read-only. Compared to copying hundreds of GB for no reason, I’d be happy to execute a Terminal command or two.

I suspect the problem is caused because WD drives spin down regularly and take longer than macOS would like to spin back up. They are then designated as read-only because the OS has had difficulties accessing them multiple times.

This Mac is running a pristine version of Sierra, installed about two weeks ago after erasing the internal drive. I do not manually change system files or install programs which modify system files (cache-cleaners, etc.).

The drives are not damaged. I have checked them many times on multiple computers. Unfortunately, this is not the first time I’ve been locked out. Please let us work on the assumption that they are in good working order.

The drives appear in the finder on restart only.

Once unmounted (ejected), I cannot remount them using:

• the GUI Disk Utility
• diskutil
• mount (the -uw option doesn’t work on hfs as demonstrated with -dv), or
• mount_hfs

I can read from the drives.

I tried Nicholas Vahalik’s idea of turning off journaling with hfs.util and running fsck_hfs. hfs.util worked, but the disk wasn’t journaled. fsck_hfs was unable to write to the drive.

I am unable to change permissions using the Finder or the shell, but they appear to be set correctly for my user to have read/write access anyway.

Both drives contain some hidden files in their root directories. I suspect one (or more) may have locked the file system. In other words, when the OS goes to use the drive, if it sees one of these files present, it designates it as read-only. The suspect files are:

• .apdisk (apparently a new apple fs?)
• .fseventsd (a directory, but may contain something pertinent)
• two others I’ll need to reboot to see again. Something like .diskID and .diskIDx2

However, I cannot access the above files to move or delete them for testing purposes.

There is something «higher-level» going on that prevents write access on the drives. Any help determining what that is, would be appreciated!

Mac mini, macOS Sierra (10.12.1)

Posted on Oct 26, 2016 9:24 AM

All replies

Loading page content

Page content loaded

How are they formatted?

Oct 26, 2016 9:27 AM

Oct 27, 2016 8:57 AM

Thats correct (except for the lack of journaling), but doesn’t explain why they don’t write. Can you temporarily move the content of one of them off the drive and reformat it correctly?

Oct 27, 2016 9:01 AM

$ diskutil info disk3s2

has revealed that the drives are «Read-Only Volumes,» but I haven’t been able to discover why this is the case or how they were designated as such.

I have found that the following commands save me from having to restart the Mac to remount the drive each time:

$ sudo mkdir /Volumes/BackupDrive

$ sudo /System/Library/Filesystems/hfs.fs/Contents/Resources/hfs.util -m disk3s2 /Volumes/BackupDrive fixed readonly nosuid nodev

The fixed flag came from the diskutil info command above. The readonly flag appears to be required, as writeable (or «writable» in the error message, also see man entry) will not work.

The fact that the writeable flag will not work makes me think that the file system has been set to read-only in some other way. It is not simply a matter of deliberately mounting it rw. I have tried chmod, xattr, and attempted to change the UUID (hfs.util -s) of the partition in the hope that this would separate the drive info from whatever is designating it read-only. This was unsuccessful.

I suspect this is less complicated than it seems, but no solution yet.

This does seem to be a common problem, and has been for many versions of macOS.

Источник

How to Enable Write Access on Root Volume on macOS Big Sur and Later

EliteMacx86

Administrator

How to Enable Write Access on Root Volume in macOS Big Sur

An EliteMacx86 Exclusive Guide — This guide covers mounting of system root volume on macOS Big Sur. By following this guide, you’ll be able to have write access onto the system’s root volume.

Overview

Recently, Apple announced their new macOS lineup i.e macOS Big Sur 11.0 which is Apple’s newest and most awaited OS. Catalina adding massive updates and improvements from its predecessor, Mojave.

Packed with new features and functionality, the most noticeable update can be seen and experienced is the new GUI. Featuring a much more «iOS» look and feel and as smooth as butter. Along with this, Apple has introduced some security protection which prevents the writing to system’s root volume. Since macOS Catalina, Apple has split the OS and user data into two volumes where the system volume is «read-only» by default which prevents modification of system root volume.

A very quick way to mount system volume was to use «sudo mount -uw /» in Terminal. However, with Big Sur, this doesn’t works and the command throws an error. If you’ve attempted to make the root volume as writable using the command which works on macOS Catalina, you might be familiar with the following error.

With macOS Big Sur, Apple added some more protection and unfortunately the system root volume cannot be mounted. The error is very normal on Big Sur and the above command will not allow you to mount the system’s root volume. In macOS Big Sur, the «System» directory has been completely sealed and it will not accept any changes. All the kexts which you used to install into S/L/E, now gets installed onto L/E instead. Even if you attempt to install Mojave or Catalina and you have some third party kexts on S/L/E and proceed with an update, the system will remove those kexts and you’ll have those kexts in a folder at your Desktop after the upgrade. However, installing the same kexts to L/E directory will work and will load too. But there are kexts which must be installed in S/L/E to be particular and as Big Sur doesn’t gives you the option, you’re out of luck.

Why writing to System’s Root Volume is Required?

The real question comes that why do you need to mount the system’s root volume and modify it when Apple doesn’t allows it? A simple answer is in some environments, this can be needed for some special purpose such as Hackintosh where you may have a need to modify the kexts in S/L/E directory or even for the real Mac users who are willing to run macOS Big Sur on their unsupported Macs.

Mounting System’s Root Volume

Interestingly, there is an actual workaround for mounting the system’s root volume and having write access to it. Where you can modify the files and make the changes. To enable write access onto your system’s volume, follow the steps outlined below.

WARNING:

Due to the update functionality in macOS Big Sur, changing the system volume can break OS updates. By using this guide, you understand all the risks involved and EliteMacx86 shall not be liable for any of the damages that might occur and takes no responsibility for any of your action. Please proceed with caution!

Creating Mount Point for the volume
The very first step is to create a mount point for the volume where the system’s root volume will be mounted. To create the mount point, execute the commands below.

1. Open Terminal.
2. Type:

Finding the required Disk Identifier
The next step is to find the target disk name for mounting. To find the disk name, follow the steps below.

1. Open Terminal.
2. Type:

3. This will list all the connected drives on the system. You’ll find something similar like the screenshot attached below. The disk name are hidden for the privacy reasons.

4. The /dev/disk2 is the actual disk and the capacity is 250GB. The APFS container has been created on disk2 as /dev/disk5 which is the system. A very quick way to determine the disk identifier is finding one with «synthesized» and look for the system’s volume name. In our case, it’s Macintosh HD, your’s could be different from ours. Once you locate the volume name, just check for the identifier. In our case, the volume name is «Macintosh HD» and the identifier is «disk5s5» and that’s the disk name we’re looking for.

Mounting Drive
The next step is to mount the drive into the directory «livemount» we created in the very first step. To mount the drive, follow the steps below.

1. Open Terminal.
2. Type:

3. You’ll be prompted for the password. Simply enter your system’s password and press enter.

Finding Mounted Volume
Now, as you have mounted the volume, you’ll need to open the mounted volume for write access. To open the mounted volume, there are two ways.

1. Open Finder.
2. Type:

The other way is to manually find the path. The path for the mounted volume is
Macintosh HD/Users/Yourusername/Macintosh HD

Notes:

• The Macintosh HD may differ from your actual system’s volume name.
• «Yourusername» is your user name.

Rebuilding Kernel Cache
If you have edited either S/L/Kernel, S/L/E directory, you’ll also need to rebuild a kernel cache

Creating Snapshot
Once you have finished editing the system volume, you’ll need to create a new snapshot. To create a new snapshot, follow the steps below.

Источник