Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

.fseventsd folder not re-generated after removal

MaiKAimer

MaiKAimer

macrumors newbie
Original poster
Dec 26, 2022
10
0
New Zealand
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.
 
You can try from Terminal:
Code: 
sudo mdutil -E /System/Volumes/Data
-E Erase and rebuild index
or

Code: 
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).
 
bogdanw said:
You can try from Terminal:
Code: 
sudo mdutil -E /System/Volumes/Data
-E Erase and rebuild index
or

Code: 
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).
Click to expand...
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?
 
Restart your Mac, it should be recreated after that. I've just tested in Monterey 12.6.4 (21G526)
 
You could try to create the folder
Code: 
sudo mkdir /System/Volumes/Data/.fseventsd

and see if it's used later
Code: 
sudo ls -a /System/Volumes/Data/.fseventsd
 
bogdanw said:
You could try to create the folder
Code: 
sudo mkdir /System/Volumes/Data/.fseventsd

and see if it's used later
Code: 
sudo ls -a /System/Volumes/Data/.fseventsd
Click to expand...
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.
 
MaiKAimer said:
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.
Click to expand...
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.
 
Last edited:
Worked like a charm. Thank you very much. I did

Bash: 
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.
 
MaiKAimer said:
Worked like a charm. Thank you very much. I did

Bash: 
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.
Click to expand...
Glad it worked.

MaiKAimer said:
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.
Click to expand...
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.
 
chown33 said:
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.
Click to expand...
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.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back