Spotlight is indexing my external drives even after generating .metadata_never_index

I have a script that reformats an external drive as HFS+, then it disables journaling on the drive, then it disables spotlight indexing via creating a file named ".metadata_never_index" at the root level.


Then the script looks up the amount of free bytes on the drive, divides by 25 megabytes, and loads that many *exactly* 25 MB files on to the drive.


Doing this should leaves me with anywhere between 24.9999999 MB to 0 bytes on the drive.

What actually happens is that every single time I run this on the same drive, I get a different amount of free space left. Sometimes theres no free space left, and the task runs out of space before it can generate all of the 25 MB files.


I don't know if this is the entire problem, but a big part of the problem is that despite creating the .metadat_never_index files, I still get spotlight indexes on the drive. Right now for example, the last time I ran this script on a 250 GB drive, it was unable to finish and when it stopped, it had almost 600 MB in .Spotlight-V100


Now I do have a separate "buffer" amount I subtract from the total free space, before I divide by 25. But sometimes it's not enough because I'm always getting different end results from doing the exact same task over and over. Every last file is 25MB to the byte (except in instances where the drive fills up and it cant finish).


So my primary question is, how else can I truly stop spotlight indexing, from the drive level.

And the second question is, more generally, how can I get consistent results here? I'm going to keep doing more tests and logging the results to try to see if the problem is ALWAYS just the spotlight indexes, or if there are other things that are not adding up, size-wise.

Mac mini, macOS 12.7

Posted on Dec 27, 2025 4:15 AM

Reply
Question marked as Top-ranking reply

Posted on Dec 31, 2025 8:37 PM

l008com wrote:

EDIT: Once again, figured it out. The command to kill indexing was returning this weird error, something like 'spotlight busy, try again later'. So I had to add a random 2 second delay to my script to give whatever is going on, time to "settle" before I can turn off indexing. Thats incredibly annoying. I'd much rather the command make me wait for its competition, vs fail in a way that is unpredictable.

Good job figuring it out.


FYI, it is always best to test the commands only on the command line at a command prompt to confirm that they work as expected and to see if you notice any issues. Only once you confirm commands work individually at the command prompt can you test a script using them since some commands may end behaving differently in a script than at the command prompt.....and if automating things, once again things can affect a script even if the script worked when launched manually.

6 replies
Question marked as Top-ranking reply

Dec 31, 2025 8:37 PM in response to l008com

l008com wrote:

EDIT: Once again, figured it out. The command to kill indexing was returning this weird error, something like 'spotlight busy, try again later'. So I had to add a random 2 second delay to my script to give whatever is going on, time to "settle" before I can turn off indexing. Thats incredibly annoying. I'd much rather the command make me wait for its competition, vs fail in a way that is unpredictable.

Good job figuring it out.


FYI, it is always best to test the commands only on the command line at a command prompt to confirm that they work as expected and to see if you notice any issues. Only once you confirm commands work individually at the command prompt can you test a script using them since some commands may end behaving differently in a script than at the command prompt.....and if automating things, once again things can affect a script even if the script worked when launched manually.

Dec 31, 2025 6:17 AM in response to l008com

mdutil  -i  off  /Volumes/<mounted-name>


You can check the Spotlight status of a particular volume with:


mdutil  -s  /Volumes/<mounted-name>


So I'm still having trouble. When I run the first command, the "-i off" command, it says it's disabling indexing. THEN I use -s to check the status and indexing is still enabled. And it DOES still index, I still end up with a few hundred MB of index!



I don't get it. All of this happens AFTER the drive is reformatted, so its nice and fresh. Its not trying to disable it, THEN reformat thereby resetting the indexing status. So I don't get it.


EDIT: Once again, figured it out. The command to kill indexing was returning this weird error, something like 'spotlight busy, try again later'. So I had to add a random 2 second delay to my script to give whatever is going on, time to "settle" before I can turn off indexing. Thats incredibly annoying. I'd much rather the command make me wait for its competition, vs fail in a way that is unpredictable.

Dec 27, 2025 10:48 AM in response to l008com

You can use the following command template which is better just in case Apple changes how it identifies whether Spotlight is enabled on a volume. Replaced "<mounted-name>" with the actual name of the mounted volume. Make sure to properly escape any spaces in the name or place the name in double quotes if the name includes spaces.

sudo  mdutil  -i  off  /Volumes/<mounted-name>


You can check the Spotlight status of a particular volume with:

sudo  mdutil  -s  /Volumes/<mounted-name>



Now, my big concern is why are you completely filling up a drive like that? I see a lot of potential problems there.


Even a read only data drive should have more Free storage space than just 25MB. I would highly recommend having at least 1-2GB of Free space as a buffer zone depending on the file system involved. Bad things can happen if a drive completely runs out of Free storage space. Accidents do happen so you may find something may fill up that small 2GB buffer zone. Like I said, very bad things happen when a drive completely runs out of Free space.


What type of drive(s) is involved here? If it is an SSD, then doing this on an SSD will wear out the SSD much faster since SSDs have a limited number of lifetime Writes. While SSDs do have a small built-in buffer zone of spare NAND blocks (over provisioning), this is not always sufficient for optimal SSD performance. Leaving some space open on an SSD can help with the SSD's performance as well as helping to extend the life of the SSD's NAND blocks which have a limited number of lifetime Writes.


Filling a 256GB drive up with 25MB files can create problems with the Finder since the Finder doesn't always deal well with 10K+ files in a single folder (I'm not sure what amount will start showing problems in the Finder).


What are these 25MB files? Are they actual data you are transferring or are these just place holder files, or just meant to fill the drive? I'm thinking there may be a better way to achieve your goal, but we need to understand the intended goal.

Dec 28, 2025 3:31 AM in response to HWTech

This script does not have root access and I don't particularly want to give it root access. This .metadata_never_index file seemed to be the perfect solution because of that. I had never even heard of that option before. But it either doesn't work, or doesn't FULLY work.


Some passes, the spotlight index will be under 1 MB. Other passes, the spotlight files might be 150 MB or 250 MB or 600 MB.


This is a drive stress testing script, so all of the problems with doing this are exactly the point.

Spotlight is indexing my external drives even after generating .metadata_never_index

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.