du: /System/Volumes/Data/.Spotlight-V100: Permission denied

You are trying to find out how much disk the Spotlight index is using, and:

du -sh /System/Volumes/Data/.Spotlight-V100

du: /System/Volumes/Data/.Spotlight-V100: Permission denied

The answer is sudo:

sudo du -sh /System/Volumes/Data/.Spotlight-V100

What follows is why the other thing you were about to try, granting Terminal Full Disk Access, does not help, and how to tell these two failures apart in future so you do not spend an afternoon on the wrong one.

The directory is root-only

ls -ld /System/Volumes/Data/.Spotlight-V100

drwx--x---  4 root  _mds_stores  128 Mar 28  2025 /System/Volumes/Data/.Spotlight-V100

Read that mode carefully. Owner root has rwx. Group _mds_stores has --x, execute only, which permits traversing into the directory if you already know an exact path inside it but not listing what is there. Everyone else has nothing at all.

0710

Your user is not root and is not in _mds_stores. du has to list the directory to total it, listing requires read, and read is not granted. That is the whole failure, and it predates macOS by several decades.

Full Disk Access is not the control here

This is the part worth establishing properly, because the advice is everywhere and it is wrong for this specific error.

On the machine where I reproduced this, Terminal already had Full Disk Access. I can demonstrate that from the same shell in the same session, because Apple’s privacy database is itself protected by Full Disk Access, so being able to read it proves the grant is live:

sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db "select count(*) from access"

52

52

A shell that can read TCC.db has Full Disk Access by definition. That same shell cannot run du on the Spotlight index. The privacy grant was never the relevant control.

macOS runs two independent permission systems. Full Disk Access is a consent grant covering categories of protected data. Unix permissions are ownership and modes covering individual paths. Satisfying one has no effect on the other, and sudo addresses only the second.

Telling the two failures apart

Before you open System Settings, run two commands:

ls -ld /the/path/that/failed
id

If the mode and your identity explain the refusal, as they do here, it is a Unix problem and sudo is the answer. If the mode looks permissive and you were refused anyway, it is a privacy problem and System Settings is the answer.

The error text gives a weaker second signal. TCC refusals usually surface as Operation not permitted, corresponding to EPERM. Classic permission failures give Permission denied, corresponding to EACCES. This error says Permission denied, which points at Unix. Some tools flatten or rewrite these before printing, so treat it as a hint rather than proof, and check the mode.

What you were probably actually asking

The reason people run this command is almost always to find out whether Spotlight is responsible for missing disk space. With sudo you will get a number, and on most machines it is smaller than expected: an index is metadata, not content.

If the real question is why the disk is fuller than the files account for, the index is rarely the culprit and local Time Machine snapshots usually are:

tmutil listlocalsnapshots /
df -h /System/Volumes/Data

Snapshots are reported as purgeable rather than used, which is why the arithmetic in Finder can look impossible while df looks fine.

If the question is whether indexing itself is misbehaving, mdutil reports status without needing to read the index directory:

mdutil -s /

/:
	Indexing enabled.

That command works unprivileged. Attempting to change indexing state does not:

mdutil -E /

Error: unable to perform operation.  Try as root.  (-1)

Same underlying situation, and this time the tool says so directly rather than leaving you to work it out from a file mode.

The short version

sudo du -sh /System/Volumes/Data/.Spotlight-V100. It is a root-owned directory with mode 0710, not a privacy setting, and checking ls -ld first would have said so in one line.

The number you get, and what it means

With sudo the command completes and returns a size. On most machines it is smaller than people expect, and the reason is worth stating: the index is metadata, not content. It stores file names, paths, attributes and extracted text fragments, not the files themselves.

A working index typically lands between one and several gigabytes depending on how many files exist and how much of their content is text. A machine with hundreds of thousands of small text files will carry a larger index than one with a few thousand large video files, even though the second machine uses far more disk overall.

Two situations make the number worth checking. An index that has grown to tens of gigabytes usually indicates a corrupted or duplicated store rather than a lot of files. An index that is implausibly small on a full disk suggests indexing never completed, which shows up separately as Spotlight searches returning nothing for content that plainly exists.

mdutil -s /

That reports whether indexing is enabled per volume, and it runs without privileges. Anything other than Indexing enabled. is worth resolving before drawing conclusions from the index size.

Rebuilding, and the cost of doing it

If the index does look wrong, rebuilding is the standard remedy and it is genuinely disruptive rather than merely slow.

sudo mdutil -E /

-E erases the index and triggers a rebuild from scratch. During the rebuild, which takes anywhere from twenty minutes to several hours depending on how much data you have, Spotlight returns incomplete results, Mail search is unreliable, and the machine runs noticeably warmer because indexing is sustained work across many files.

The efficiency cores absorb most of that, which is why a rebuild on Apple Silicon is far less intrusive than the same operation was on Intel hardware. It is still not something to start fifteen minutes before you need to find something.

Note that this command needs root for the same reason du did, and it says so more helpfully:

Error: unable to perform operation.  Try as root.  (-1)

Excluding directories instead of rebuilding

Frequently the actual goal is not a smaller index but a faster or quieter machine, and exclusion is the cheaper intervention. Directories full of build artefacts, virtual machine images, or dependency trees generate enormous amounts of index churn for content nobody will ever search for.

sudo mdutil -i off /Volumes/SomeExternalDisk

For directories rather than volumes, the exclusion list lives in System Settings under Siri and Spotlight, Spotlight Privacy. Adding node_modules, a Parallels directory, or a build output folder there stops the indexer following changes into them, which reduces both index size and background CPU.

The trade is that content in those directories becomes unfindable through Spotlight, including in Finder search. For build artefacts that is exactly what you want. For a documents folder it is not.

The general shape of this problem

Worth carrying beyond this one directory: when a command is refused, look at the object before looking at the settings.

ls -ld /the/path
id

Two commands, one line of output each, and between them they explain the large majority of permission failures on macOS. The mode and the owner tell you whether your identity can do what you asked. If it plainly cannot, sudo is the answer and no privacy setting is involved.

The reason this is worth a habit is that the alternative, opening System Settings and granting broad access to a terminal, is both ineffective for this class of failure and a real widening of what that application can reach. Getting into the habit of checking the file mode first avoids granting permissions you did not need and that will outlive the problem that prompted them.