MacBook Pro M1 Pro SSD: Disk First Aid corruption loops

iamshivam wrote:

Those “resource fork xattr missing for compressed file” warnings that keep coming back with new inode IDs are almost never raw SSD failure, especially on Apple NVMe (your SMART + wear stats look perfectly healthy), they’re usually metadata inconsistencies being reintroduced at the file level after a clean install, your pattern (clean system > fine > data/apps come back > warnings return) points straight at something in user space constantly writing slightly broken compressed files, not the filesystem failing to repair itself, the big clues are your heavy I/O, Dropbox + OneDrive + CCC all touching the same files, plus QuickLook/mediaanalysisd crashes, APFS compression + extended attributes get weird when files are synced, indexed, previewed, and backed up simultaneously, especially with non-FileProvider setups like your Dropbox config, so First Aid “fixes” them but the same pipeline recreates them, the reason you can’t resolve those inodes is likely because they’re transient or already deleted/replaced by the time you look.

I've sometimes wondered why I am able to stress an m1 mac with rather average usage.

What I’d do- temporarily kill the variables instead of chasing inodes, pause Dropbox/OneDrive, disable CCC scheduled tasks, reboot, then run fsck_apfs from Recovery once, if the warnings stop reappearing after a day or two of normal use, you’ve confirmed it’s software churn, not disk damage.

ok. Dx is paused indefintely, Onedrive is unlinked and CCC scheduled tasks off since this morning. Right now, 10 hours later, the errors are still there and return in Recovery, but I'll watch.

If they still come back even with all sync/backup tools off, then I’d start suspecting a deeper APFS/container issue, but right now this looks like metadata being dirtied faster than Disk Utility can keep it clean, not a dying SSD.

thanks for this assessment, I'll write how it goes.

iamshivam wrote:

What I’d do- temporarily kill the variables instead of chasing inodes, pause Dropbox/OneDrive, disable CCC scheduled tasks, reboot, then run fsck_apfs from Recovery once, if the warnings stop reappearing after a day or two of normal use, you’ve confirmed it’s software churn, not disk damage.

If they still come back even with all sync/backup tools off, then I’d start suspecting a deeper APFS/container issue, but right now this looks like metadata being dirtied faster than Disk Utility can keep it clean, not a dying SSD.

It's day 2 since doing all of this. They're gone. Thanks so much! I learned a lot here.

---

just for the records

• Deleted the snapshots to be able to see.
• The warning about the APFS version I know, the update from 15.6.1 (the genius bar new install) to 15.7.4 won't update the recovery system and this doesn't matter, just don't use -o.

Running First Aid on “Data” (disk3s5)

Checking file system and repairing if necessary and if possible.

Volume was successfully unmounted.

Performing fsck_apfs -y -x /dev/rdisk3s5

Checking the container superblock.

Checking the checkpoint with transaction ID 1674074.

warning: container has been mounted by APFS version 2632.80.1.0.1, which is newer than 2332.140.13

warning: disabling overallocation repairs by default; use -o to override

Checking the space manager.

Checking the space manager free queue trees.

Checking the object map.

Checking the encryption key structures.

Checking volume /dev/rdisk3s5.

Checking the APFS volume superblock.

The volume Data was formatted by newfs_apfs (2332.140.13) and last modified by apfs_kext (2332.140.13).

Checking the object map.

Checking the snapshot metadata tree.

Checking the snapshot metadata.

Checking the document ID tree.

Checking the fsroot tree.

Checking the extent ref tree.

Checking the file key rolling tree.

Verifying volume object map space.

Verifying allocated space.

The volume /dev/rdisk3s5 with UUID xxx appears to be OK.

File system check exit code is 0.

Restoring the original state found as mounted.

Operation successful.

---

etresoft wrote:

I don't have any problems with 16 GB here, and I'm a heavy Xcode user.

Very interesting, I think I should be fine then. Maybe I'm just using my mac wrong. Closing one thing before opening the next is good for brains and computers.

The way I found that in the first place was because of some errors in a CCC backup and the advice to check the drive with Disk Utility. So I did, and then found that the internal SSD had them too.

Sounds like a problem with that app. 3rd party backup apps have really struggled since Apple switched to the APFS file system a few years ago. In their defence, Apple's APFS file system really isn't amenable to 3rd party backup systems.

It was initially Cookie, a Cookie management app that lets me choose which cookies to keep and which to delete when I quit Safari. It would not see any Safari cookies, but would work fine on a new user. If I go through all of that I might as well do a clean install. When checking the backups to prepare the move I saw the corruptions, time machine drive had them as well.

I noticed how CCC struggles. But the two times in 30 years that I had to really restore from backup because the hard drive crashed, it was Time Machine that could not restore for no reason given, and CCC saved my data. Since then I've been doing both on alternating schedules.

These days, I would recommend using iCloud. The last time I tried to use Time Machine, I encountered corruption in a couple of systems that had their own data validation.

iCloud restored very wel during the clean install. But it offloads things even if I tell it not to. I am without internet so often that this will get me into trouble.

I still have Dropbox in my home folder and refuse to use File Provider or any smart sync features. Everything is on my drive at all times. It is reliable but may use a lot of resources.

What you describe with Calendar could be easily explained by corruption of data files. That doesn't necessarily mean there is any corruption at the file system level. And since you did an erase and reinstall without restore, then that would have corrected any file-level or filesystem-level corruption.

Ok, comforting to know. Since the full erase and clean install things are much better. Except for these many crashes from the Etrecheck report. I'll try and use stable versions, not betas or TestFlight, and go easy on the quicklook browsing.

Unless you're experiencing some specific, identifiable problem, then I recommend not looking for low level errors. Modern systems are so complicated that you will always find massive levels or errors and failures if you go looking for them. Since you can't fix them, and they occur on all systems everywhere, it's not worthwhile to even try looking for them unless you already have an identifiable problem first.

Complexity is an argument. I was on the lookout for the 31 corrupt zips that I wouldn't find out were corrupt until the good version was long erased from any backup.

I'll call it OCD, have some chocolate to calm me down and stop checking : ) Thanks!

HWTech wrote:

Run First Aid until the errors & warnings are gone. If after several scans the errors/warnings remain, then run First Aid from Recovery Mode. If after several scans the errors/warnings remain, then they cannot be repaired. How you deal with that depends on where those errors/warnings are located.

FYI, you cannot trust the First Aid summary....this is from personal experience.

Here is an Apple article with instructions for using First Aid......Apple now has users running First Aid while booted into Recovery Mode these days. It is important to run it on the hidden Container as well....Apple mentions how to do this.

How to repair a Mac storage device with Disk Utility - Apple Support

If the errors/warnings are on a:•

snapshot, then those errors/warnings will be gone when that snapshot is deleted

• Data volume, then a simple "Erase All Content & Settings" will delete the corrupted volume & create a new one once you go through Setup Assistant again

• Container.....this requires erasing the disk (aka the "Volume Group") by using Disk Utility followed by reinstalling macOS & restoring from a backup.

These errors would loop even from Recovery. That's why I went to the genius bar and had it erased with Apple Configurator. I thought that they would erase everything and took great care to clean install afterwards. The errors (warnings) were gone after moving back data was complete, I was checking for a few days after the install and all was fine. But now I have warnings again. The inode IDs are different from before.

They are not in a snapshot, I deleted all snapshots, there were just a few anyway after the install. They only show up when I check Data, and the inode numbers are always the same, but different from before the genius bar erase.

That's why I was wondering whether the SSD was ok.

etresoft wrote:

If you're trying to locate a file by inode, you can do the following:

Assuming the file is on your startup volume. First, get the volume number using a known file, like so:

/ $ stat /etc/hosts

16777230 116335094 -rw-r--r-- 1 root wheel 0 364 "Jun 16 16:20:21 2025" "Jun 16 16:20:19 2025" "Feb 12 12:36:13 2026" "Jun 16 16:20:19 2025" 4096 8 0 /etc/hosts

That first number is the volume number.

I assume you already have the inode. To test, you can get the inode of another file using the same command. The inode is the second number above.

Then, use a special "reference URL" with the following command to get more info about the file:

/ $ GetFileInfo /.vol/16777230/116335094

file: "/private/etc/hosts"

type: "\0\0\0\0"

creator: "\0\0\0\0"

attributes: avbstclinmedz

created: 06/16/2025 16:20:19

modified: 06/16/2025 16:20:19

Interesting. The files from the Disk utility warnings give

GetFileInfo: could not refer to file (-43)

I do get something for other files, so it works. inode id figured out with stats and the path same as above.

%  GetFileInfo /.vol/16777231/14451426

file: "/Users/xxx/Downloads/xxx.txt"

type: "\0\0\0\0"

creator: "\0\0\0\0"

attributes: avbstclinmedz

created: 03/15/2026 09:57:15

modified: 03/15/2026 09:57:15

(edit: I have % at the prompt, not $. not sure why)

Thanks much for your reply. Good that you say that.

I see no problems with the files I am using now (except for realizing that Apple people said 16 GB of RAM is enough for normal use with M1 and it's not, I have a lot of swaps and often quit and restart apps to free up memory, hence I considered it possible that I have more wear on the SSD). But I'd expect to have to open the file that has the corrupt metadata, and I have no clue which file that is.

The way I found that in the first place was because of some errors in a CCC backup and the advice to check the drive with Disk Utility. So I did, and then found that the internal SSD had them too.

oh I remember: I had the backup drive on an unpowered hub for a while, a long time ago, and then made a quick reinstall because I badly messed up some Calendar entries.. So I thought that's where the internal SSD got corrupt files. Then I did this "erase and clean install no migration" with the help of the App store genius bar, and now ther're back.

But I accept if you say theyre harmless.

Grant Bennet-Alder wrote:

another opinion:

Time Machine is doing more frequent checking of its stored backup data, and its availability has improved dramatically in more recent versions.

True. I often get a previous version of a file with Time Machine. Dropbox History is for shorter time spans.

I do have both Time Machine and CCC. Before taking it to the Apple Store I made a third backup. I'm just keeping my old Time Machine for a bit to see if I still need something.

etresoft wrote:

schmunzelmonster wrote:

Very interesting, I think I should be fine then. Maybe I'm just using my mac wrong. Closing one thing before opening the next is good for brains and computers.

I tend to keep everything running. I only restart when I do updates, which I do much less often than most people these days. Perhaps you should start a new question specifically about this problem.

Ok, will watch this and do if issues resurface, thanks. When I wrote this I think I mixed up with frequent old issues. Since the clean install I have almost no memory pressure. So maybe my issues were because I migrated from Intel to M1 instead of clean installing right away.

It was initially Cookie, a Cookie management app that lets me choose which cookies to keep and which to delete when I quit Safari. It would not see any Safari cookies, but would work fine on a new user.

That might be a problem with that app. It's always a challenge trying to hack around on the internal data of another app

yes, I try to install very few. But always deleting via prefs > security > Website Data is impractical too. I never had Facebook, or I did, for a second. Too much of a mess. I really suffer from the bombardment with familiar ads, I forget what I wanted in the first place. It is very taxing.

when something breaks, they never realize that they caused the problem 18 months ago. They think because it surfaced with an OS update that the OS update directly caused it. That's a very difficult kind of error loop to get out of.

I certainly do this a lot.

I think you do have some corrupt files somewhere and that's what's causing the QuickLook and mediaanalysisd crashes.

Would be interesting to find them. Quicklook I do on newly downloaded things to browse through them and delete most, these are sometimes corrupt. I also quicklook my Dropbox Camera Uploads photos. I take a lot of documentary photos of things done and appreciate the date and time stamp and the ability to file them away in project folders. Inside the Photos app, they're useless for me except for the map function which is nice for spare time but useless for work. I can't regenerate my folder tree inside every app, I need the picture next to the excel and the md file with the zotero links to the pdf to be able to think.

I've tried to figure out what files those inode numbers correspond to with the Mints app referred to here https://eclecticlight.co/2025/06/17/when-and-how-should-you-run-first-aid-in-disk-utility/ but just get an error 3. That seems to mean they're not important or even gone.

But those Zotero crashes are more interesting. If you're getting corrupt data in Safari, I would be more inclined to blame Zotero and its crashes more than Cookie.

It's the Zotero Connector Safari extension that crashes when I leave too many tabs open. Zotero itself is extremely stable. The Safari extension is just installed together with the app, not via Extensions. Zotero would work perfectly with Firefox. Maybe I just shouldn't use Safari for it.

thanks for all the input. much appreciated.