fs tree invalid on APFS

The subject line is misleading—fsroot tree—

I had to go back to the top to read

Checking the fsroot tree.

error: drec_val object (oid 0x51b169): invalid type (0)

fsroot tree is invalid.

The volume /dev/rdisk1s1 could not be verified completely.

To Answer your question corrupt APFS

You can read several reference to problems in the Beta:

APFS Brand new filesystem corruption | Apple Developer Forums

https://swissmacuser.ch/solution-fixing-macos-highsierra-apfs-issue-fsroot-tree- invalid-in-beta-17a315i/#.WdopwIZrzOQ

Installed High Sierra twice on a Macbook Air 11inch 2010 and Macbook Air 13 inch mid 2013. No problem at all.

Today i installed high Sierra for the first time on my Macbook pro mid 2011 with 1TB SSD. First-aid check is way to fast done in less then two seconds. Having a closer look i see:

error: drec_val object (oid 0x2): invalid type (0)

fsroot tree is invalid.

The volume /dev/rdisk1s1 could not be verified completely.

Same as the topic starter.

Is it a concern or not?

I just found this: https://swissmacuser.ch/solution-fixing-macos-highsierra-apfs-issue-fsroot-tree- invalid-in-beta-17a315i/#.WfzDcbZx_OR

I'm having important issue

macbook pro late 2010 after high sierra installation

fsroot tree error on disk utility

most important ----> disk does not gain capacity when deleting files!

samsung ssd as main disk

Same configuration, same problem

MackBook Pro 13 late 2010, Samsung SSD 250Go

fsroot tree error, and system is taking all available space, letting me 1Go free space (on 250Go, 230Go taken by system)

I've try to make big file with mkfile, the system allowed it, but when i delete them, freed space goes back to system.

No more disk capacity to make updates too

I got the exact same error when running Disk Utility on my MBP 15-in. (2016) after upgrading my OS to High Sierra 10.13.1. After applying the "root" security fix, on reboot my laptop just hung for about 20 minutes before I had to do a forced shutdown. Thankfully it rebooted and seemed to run okay afterwards. However, doing a Disk Utility First Aid check reported that the "fsroot tree is invalid". Hopefully, Apple will develop a fix to correct this issue (if in fact it is a critical issue) before it degrades my file system even more.

same problem as op after I went from Sierra to High Sierra (and therefore APFS) on a 13” Early-215 MBP (Bootcamped) a few days ago

disk utility can’t run in recovery or otherwise, always reporting “fsroot tree is invalid”. I get “error: drec_val object (oid 0x200be4): invalid type (0)” as the error myself

I'm also finding a few random error 43 permissions problems on my files and found files where the permissions had been wiped, There was nothing wrong with permissions or disk before installing High Sierra

I’d like to know if waiting for Apple is an option, or if Apple now won’t be able to fix my drive, so I have no option but to wipe and rebuild?

swissmacuser has apple acknowledge a bug related to this: https://swissmacuser.ch/macos-highsierra-beta4-17a315i-breaks-apfs-formatted-dri ve-issue/#comment-91344

so what is bug 33949235 and what is its status?

It's seems that the upgrade from the previous FS to APFS via high sierra upgrade cause the problem on non-apple disk (SSD only ??).

I've try something that have might work:

- make a bootable backup of disk with Copy Carbon (that take only the good files, so the good file size)

- boot on backup

- format completely my SSD and make a new APFS partition

- restore backup on it

- boot normaly on SSD

and now every things seems ok. No more space taken by the system so long (1 week).

Remember that your are responsible of your data by doing this, take good care to make more than one backup of your files

Update:

After installing the latest update (10.13.2) on Dec. 11, the error has now been fixed on my MBP (2016). When running First Aid in Disk Utility, I now get the following report:

Verifying file system.

Volume could not be unmounted.

Using live mode.

Performing fsck_apfs -n -l -x /dev/rdisk1s1

Checking volume.

Checking the container superblock.

Checking the EFI jumpstart record.

Checking the space manager.

Checking the object map.

Checking the APFS volume superblock.

Checking the object map.

Checking the fsroot tree.

Checking the snapshot metadata tree.

Checking the extent ref tree.

Checking the snapshots.

Verifying allocated space.

The volume /dev/rdisk1s1 appears to be OK.

File system check exit code is 0.

Restoring the original state found as mounted.

Operation successful.

Hope the 10.13.2 works for everybody else.

It was the last backup before I discovered the issue - literally from two hours earlier having spent the two hours trying to find a solution.

The issue occurred when upgrading to 10.13.3, which was the version that was restored - so the same High Sierra version. I only restored the system snapshot and not the whole volume, so no erasing and no lengthy process. Less than five minutes.

I guess I could have gone back to 10.13.2 backup but in my case there was no need.

For me, this is only a temporary fix.

Several times a week, I have to use tmutil to delete the dataless local snapshots to get Disk Utility First Aid to run to completion.

If there is any way to prevent these dataless snapshots from being created over and over, I would love to hear it.

-N