As a failsafe, I booted into single user mode ( see my advice for special key commands on bootup! :] ), and I ran 'fsck -fy', and it passed there as well.
Omnidisksweeper sudo verification#
(b) The drive passes verification in First Aid. Here are responses to everything you mentioned: Note: I made sure to clear all cache locations that I know of, as well as /tmp. So, I really do think that there is a file(s) somewhere outside the reach of normal user mode taking up the space. Is it a monolithic VMDK rather than being split into multiple files?ĭempson, thank you for all of the thoughts - before I respond to them, I want to point out that OmniDiskSweeper is the only source that is notreporting the same size.
Omnidisksweeper sudo free#
the file system wasn't defragmented), so the file system still has used space around the 80 GB mark and cannot be shrunk smaller than that, despite having a lot of free space before that point. (c) Something to do with the shrink mechanism not working as planned (e.g. Special keys at startup are difficult to time right with a VM (unless there is some trick I haven't learned).
OS X Recovery) or start up in single user mode (Command-S at startup) and use 'fsck -fy'. You can run Disk Utility's "First Aid" in the guest to check for this, but if it finds any problems then fixing them might be tricky because you need to either boot from a different volume (e.g. (b) Corrupted file system, such that the actual used space and reported used space don't match. (a) Does the VM have a partitioned drive and one of the other partitions is using a lot of space? You can easily check this in Disk Utility. Some remaining possible explanations which occur to me: If there were any such files, their size would count toward the used space on the volume as shown by Disk Utility and df (and Finder, apart from it pretending local snapshots are free space). If Finder, Disk Utility and df -h are all showing the same "used" figure and that is close to the total reported by OmniDiskSweeper, then the problem is not hidden/protected files. If df also shows about 11 GB used then the explanation is probably something to do with the structure of the VMDK and VMware's ability to shrink it. df will show the actual used/free space, so Local Snapshots count toward its used space. They are supposed to be deleted automatically by the system as free space gets low. KiB/MiB/GiB rather than number of blocks, but note that it uses base-2 units, whereas Finder uses base-10, thus df should show numbers that are about 2% higher than Finder for KB, 4% higher for MB, 7% higher for GB.įinder deliberately hides some things from its reported used space, in particular Time Machine's Local Snapshots (which should only exist if Time Machine is enabled in the VM). The -h option displays the results in human-readable form, e.g. The df command shows disk free and used space. (b) If the guest Finder's Get Info shows about 11 GB used space, then double check using the following command in Terminal: You'll need another method to search with admin privileges (which I can detail once I know this is the case). (a) If the guest Finder's Get Info shows about 80 GB of used space, then the problem is likely to be files in a location that your user account doesn't have permission to access, so OmniDiskSweeper isn't counting them. In particular, what do you see in the guest Finder's Get Info for its hard drive? Is that figure also about 80 GB, or is it showing a more reasonable number around 11 GB?ĭepending on the answer to that question, there are two possible routes to tracking down the problem.
But backing it up to your own external harddrive then removing it from cloud space is a lot more difficult then I thought it would be. Majourity of my storage is used by my photos. So I’m not sure why but I have this urge to just discconect from iCloud Compleltely so I’m going to show you how I did that.
But I’m having difficulty with trying to sync iCloud to Synology and my MacBook. I’ve been wanting to use it as my main backup, and basically not have to pay for iCloud storage again.