.fseventsd folder not re-generated after removal

[MaiKAimer]

For some stupid reasons, I removed /Volumes/Data/.fseventsd folder in recovery mode terminal, and after a normal reboot, when I checked in the MacOS terminal the .fseventsd folder is not re-generated under /System/Volumes/Data (and was still not re-generated after hours of use).

Inside Activity Monitor I can see that the fseventsd process is running but is mostly idle. Should I worry about anything regarding the missing .fseventsd folder in the Data volume in this situation? Any advice would be appreciated and thanks in advance.

 

[bogdanw]

Try to Rebuild the Spotlight index as explained here https://support.apple.com/en-us/HT201716

 

[MaiKAimer]

Try to Rebuild the Spotlight index as explained here https://support.apple.com/en-us/HT201716

Sorry I forgot to mention, I already re-indexed Spotlight after I removed the .fseventsd directory. It did not bring the removed .fseventsd directory back.

 

[bogdanw]

You can try from Terminal:

sudo mdutil -E /System/Volumes/Data

-E Erase and rebuild index
or

sudo mdutil -d -i off /System/Volumes/Data
sudo mdutil -i on /System/Volumes/Data

-i (on|off) Turn indexing on or off.
-d Disable Spotlight activity for volume (re-enable using -i on).

 

[MaiKAimer]

You can try from Terminal:

sudo mdutil -E /System/Volumes/Data

-E Erase and rebuild index
or

sudo mdutil -d -i off /System/Volumes/Data
sudo mdutil -i on /System/Volumes/Data

-i (on|off) Turn indexing on or off.
-d Disable Spotlight activity for volume (re-enable using -i on).

I just followed what you advised but still didn’t work (the Spotlight index was successfully rebuilt, but the .fseventsd folder is still absent), not even by restarting, re-indexing and then restarting.

Are you sure the issue is Spotlight related?

 

[bogdanw]

Restart your Mac, it should be recreated after that. I've just tested in Monterey 12.6.4 (21G526)

 

[MaiKAimer]

Restart your Mac, it should be recreated after that. I've just tested in Monterey 12.6.4 (21G526)

Weird that no matter how many restarts didn't work on MacOS Ventura Version 13.3 (22E252).

 

[bogdanw]

You could try to create the folder

sudo mkdir /System/Volumes/Data/.fseventsd

and see if it's used later

sudo ls -a /System/Volumes/Data/.fseventsd

 

[MaiKAimer]

You could try to create the folder

sudo mkdir /System/Volumes/Data/.fseventsd

and see if it's used later

sudo ls -a /System/Volumes/Data/.fseventsd

Might be a feasible solution. Will the permission be properly set by sudo mkdir command? As the .fseventsd directory should be a system directory with relevant permissions different from user-accessible folders.

 

[chown33]

Might be a feasible solution. Will the permission be properly set by sudo mkdir command? As the .fseventsd directory should be a system directory with relevant permissions different from user-accessible folders.

You can check the permissions on a disk with a properly working .fseventsd directory. Or check several disks, including USB thumb drives and whatnot, and try different ones.

Operating as root when using 'sudo', any permissions or ownership can be applied with 'chmod' or 'chown'. Start by copying what's known to work.

 

[MaiKAimer]

Worked like a charm. Thank you very much. I did

cd /System/Volumes/Data
sudo mkdir .fseventsd
sudo chown -R root:wheel .fseventsd
sudo chmod -R 700 .fseventsd

At first looking into the folder there was no action taking place, after a normal reboot the directory was populated by some system files, including fseventsd-uuid and some other alphanumerically named files starting with zeros.

It seemed that Ventura 13.3 somehow lost the ability to re-generate the missing .fseventsd directory while Monterey as you mentioned automatically re-created it after a reboot. I wonder if it is intended or an upgrade-induced bug.

 

[chown33]

Worked like a charm. Thank you very much. I did

cd /System/Volumes/Data
sudo mkdir .fseventsd
sudo chown -R root:wheel .fseventsd
sudo chmod -R 700 .fseventsd

At first looking into the folder there was no action taking place, after a normal reboot the directory was populated by some system files, including fseventsd-uuid and some other alphanumerically named files starting with zeros.

Glad it worked.

It seemed that Ventura 13.3 somehow lost the ability to re-generate the missing .fseventsd directory while Monterey as you mentioned automatically re-created it after a reboot. I wonder if it is intended or an upgrade-induced bug.

My first guess is that it's a bug, but that's just a guess. It strikes me as too weird to be an intentional feature, especially considering what it took to re-enable it.

That dir is usually made when a volume is seen for the very first time, or after one is newly formatted. Maybe there's a failsafe of some kind that it won't create the dir if there are some vestiges of having seen the volume before. That's the only thing I can think of that sounds like it might be a safety feature instead of a bug.

 

[MaiKAimer]

Maybe there's a failsafe of some kind that it won't create the dir if there are some vestiges of having seen the volume before. That's the only thing I can think of that sounds like it might be a safety feature instead of a bug.

Interesting point. It makes me curious about what if I simply ignored the issue and let my machine run without .fseventsd directory at root of Data volume indefinitely.

After some basic research I found a range of articles about .fseventsd directory and the File System Events Daemon. Of the less technical, more easy-to-read ones all warned against tampering with the /.fseventsd directory (versions before Monterey the directory was under / instead of /System/Volumes/Data), but none of them elaborated on the purpose of having the .fseventsd directory and the consequences of removing it.

On the other hand, more technical articles didn't directly discuss the consequences of removing the .fseventsd directory, and the directory is mostly mentioned as a buffer zone and staging area for logs used by the FS Events Daemon. None of them sounds alarming to me if I decide to intentionally get rid of the .fseventsd directory.

Moreover, although not sure if it is advised or not, I have also seen practices of creating a no_log file at the root of the .fseventsd directory. It seems like an implication to me that the system will continue to function without .fseventsd.