El Capitan /private/var/folders cache files consuming 30–40 GB

Question

I've upgraded my MacBook Pro to El Capitan recently, and one of the first unpleasant changes, other than XtraFinder & TotalTerminal no longer being compatible, is that the system deems it appropriate to make /private/var/folders to consume up to and beyond 30–40 GB of space, causing my Mac to slow down tremendously. I understand that the files within this folder are all cache files. My only question is why this is happening, and what makes this happen? Is there any way to make it only cache apps that are actually open, or do I have to refresh my NVRAM/PRAM? It's exceedingly annoying to have my computer act like its trying to buffer 20 gigabytes all at once.

Answer 1

The answer is that yes, you are allowed to delete files from /private/var/folders/. The command

sudo rm -r -P /private/var/folders/tr/*

was able to work and no crashes came of it. Some errors were issued by the command, but no errors came from the system as a whole. I might issue a new post later on when I know more about this to understand what Apple did with El Capitan to make it act this way.

Here's a thread from the Apple website about this; it agrees that deleting tr should be safe. According to the thread, /var/folders is the new location of caches, which you can safely delete if you've closed all running apps.

UPDATE: Another reason for this behavior can be due to Spotlight indexing, especially on older models of MacBook / MacBook Pro. I recently noticed the problem happening again, and even though I had done everything I could to prevent it from continuing to happen, I was forced to watch my Mac slowly consume more than 100 gigabytes of space to some phantom process occurring in the background.

Even so, be sure to go into Settings -> Spotlight & uncheck the box for Folders indexing, and if you're like me and have a lot of music (such as over 50 gigabytes), turn off Music indexing, too. Turn off any others you may not want, as well, but Folder indexing seems to be the biggest culprit in both disk space loss and performance slowdown on older MacBook models.

Upon turning this off, I have not seen any issues. Additionally, the remaining disk space displayed in Finder now provides accurate results.

This may also apply to iOS devices, since OS X & iOS are currently being developed to match each other's functionality and features. A large portion of the Other data stored on the device may just be Spotlight indexing not giving a toot about how much disk space it consumes. It won't hurt to try turning some features / options off if you notice issues.

Answer 2

I have had the same problem with the huge "folders". The command looks like a quick way to go and I'll try this out next time I get the big files appearing.

I manage over 400 macs and this issue has been happening since 10.9 through 10.10 and now it seems 10.11. The strange thing is that it is only apparent on a certain model of iMac, 2GHZ Intel Core 2 Duo, Macs. All the other later iMacs we use dont seem to have the problem at all.

I first noticed this problem when our helpdesk got calls from students who couldnt save work and when I checked these macs the hard drives were almost full(150GB hard drives). I manually trashed the var/folders some of which were over 100GB and the space was released but the iMacs gradually fill up again.

I havent cleared any of these Macs lately to see if the 10.11 El Capitan upgrade has fixed this issue.

Answer 3

I'm unsure if this will work in everyone's case (and I know this is an old thread), but a good old-fashioned reboot is often all it takes to clear up these cache files:

http://osxdaily.com/2016/01/13/delete-temporary-items-private-var-folders-mac-os-x/

Of course, this method may not work on all setups, however I recommend this method because there are several websites which do NOT recommend deleting items in /var/folders, /private/var/folders/ or /tmp.

https://discussions.apple.com/thread/3757828

Answer 4

I had the same problem on El Capitan (MacOS 10.11). I managed to get the Terminal app started and noticed that "lsd" (LaunchServiceDaemon) was using 100% of one core.

The fix was to rebuild the Launch Services database with the command in this Apple discussion thread.