It started with a simple observation: files kept reappearing on my Nextcloud server after I deleted them. Not all files \u2014 just the ones with Windows-illegal characters in their names, like What followed was a winding investigation that spanned seven machines, multiple databases, filesystem monitors, and MySQL triggers \u2014 before a single log file revealed the truth. Along the way, I got a fascinating window into how AI agents actually reason their way through problems.<\/p>\n I run Nextcloud on a Proxmox LXC container, with sync clients on a Mac Mini, two Windows machines (NPB7 and CT8700), and Syncthing bridging to a server called TSERVER. The problematic files lived in I\u2019d already tried the obvious fixes: removed the OnTheSpot folder from all Nextcloud sync clients, deleted the files from the server, cleaned the Nextcloud filecache database. Yet every morning at 8am, I\u2019d find the files back \u2014 about 8 hours old, meaning they were created around midnight.<\/p>\n My AI assistant (myclaw, running on OpenClaw) started the way any investigator would \u2014 by checking the obvious culprits:<\/p>\n All dead ends. The assistant then dug into the databases.<\/p>\n The Nextcloud server\u2019s MySQL database ( But there was a problem with this theory: I told myclaw that we\u2019d already cleaned the filecache before, and the files still came back. So the database entries were a symptom, not the cause.<\/p>\n The Mac Mini\u2019s Nextcloud sync database ( With no clear culprit, myclaw proposed setting up comprehensive monitoring to catch the process in the act:<\/p>\n A cron job would check all these monitors every 30 minutes. The plan was Option A: wait for midnight, catch the culprit, then devise the proper fix.<\/p>\n Before declaring the monitoring setup complete, myclaw ran one more check. Here\u2019s how it described its thinking:<\/p>\n \u201cThe monitoring watches the filesystem and database, but what if That\u2019s literally it \u2014 a simple realization that there was a blind spot. The inotifywait monitors would catch what happened on disk. The MySQL triggers would catch database changes. But neither would tell us who<\/strong> was making the request or how<\/strong> it was getting to the server.<\/p>\n So myclaw checked the Apache access log on the Nextcloud server, looking for any request involving OnTheSpot paths. And there it was:<\/p>\n The User-Agent field: Not the Nextcloud desktop client. Not rsync. Not Syncthing. Not a cron job. It was FolderSync<\/strong> \u2014 an Android app that syncs local phone folders to cloud storage via WebDAV. Running at exactly midnight PST. Every single night.<\/p>\n The Apache logs told the complete story:<\/p>\n FolderSync was syncing music from my Android phone to Nextcloud every night at midnight. The phone\u2019s filesystem allows I\u2019d completely forgotten I\u2019d set up that FolderSync pair months ago.<\/p>\n After the mystery was solved, I asked myclaw how it discovered the Apache log clue \u2014 what was its reasoning process? Its answer was disarmingly honest:<\/p>\n Phase 1:<\/strong> Checked the obvious suspects (rsync, Syncthing, NC clients) \u2014 all came up empty. Getting frustrated.<\/p>\n Phase 2:<\/strong> Found 3,522 phantom database entries \u2014 got excited, but it turned out to be a dead end since we\u2019d already cleaned those before.<\/p>\n Phase 3:<\/strong> Built comprehensive monitoring. Was about to say \u201clet\u2019s wait for midnight.\u201d<\/p>\n Phase 4:<\/strong> Before wrapping up, thought: \u201cThe monitoring watches the filesystem and database, but what if the files come through the web server? We should probably check the web server logs too.\u201d<\/em> That\u2019s literally it.<\/p><\/blockquote>\n This is genuinely how AI reasoning works in practice. It\u2019s not some mystical deduction engine. It\u2019s:<\/p>\n The AI didn\u2019t have a flash of insight. It had a flash of completeness<\/em> \u2014 the realization that the monitoring stack had a gap. Web server logs are obvious in hindsight, but they\u2019re a different layer than filesystem events and database queries. The AI was thinking There\u2019s a lesson here for anyone working with AI agents: the value isn\u2019t in brilliant leaps of intuition. It\u2019s in tireless, systematic coverage \u2014 and the willingness to check one more thing before declaring the job done.<\/p>\n The investigation also uncovered a configuration quirk that had been confusing previous cleanup attempts. Nextcloud\u2019s These were two completely different directories on two different filesystems, despite the similar naming. Previous file deletions had been targeting the wrong path. The real data was in Once we deleted the files from the correct location and cleaned the filecache, the This investigation was conducted with myclaw, an AI assistant running on OpenClaw on a Mac Mini M4. The full session involved 50+ tool calls across 7 machines in about 30 minutes of elapsed time.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" The Case of the Resurrecting Files: How an AI Agent Solved a Nextcloud Mystery It started with a simple observation: files kept reappearing on my Nextcloud server after I deleted them. Not all files \u2014 just the ones with Windows-illegal … Continue reading 4*TOWN<\/code> and Cinderella:<\/code> (with a colon). I\u2019d delete them, confirm they were gone, and by the next morning, there they were again \u2014 re-created at exactly midnight PST.<\/p>\nThe Setup<\/h2>\n
Music\/OnTheSpot\/<\/code> \u2014 music downloaded by the OnTheSpot app, which cheerfully uses characters like :<\/code> and *<\/code> in filenames. Perfectly legal on Android and macOS, but illegal on Windows.<\/p>\nPhase 1: The Usual Suspects<\/h2>\n
\n
.stversions<\/code> folder did have some versioned OnTheSpot files, but those were old backups, not active syncs.<\/li>\nPhase 2: The Database Rabbit Hole<\/h2>\n
oc_filecache<\/code>) still had 3,522 entries<\/strong> for OnTheSpot \u2014 even though the physical files were deleted. This looked like the smoking gun. If the database thinks the files exist, maybe Nextcloud\u2019s cron job was
\n\u201crepairing\u201d the filesystem by recreating them.<\/p>\n.sync_aa50e5792f27.db<\/code>) had 4 OnTheSpot stub entries, and the selectivesync<\/code> table showed OnTheSpot was explicitly
\nexcluded. NPB7 and CT8700 had zero OnTheSpot metadata entries. None of
\nthis explained the midnight resurrection.<\/p>\nPhase 3: Building the Trap<\/h2>\n
\n
oc_filecache<\/code> to log any INSERT or UPDATE for OnTheSpot paths<\/li>\nPhase 4: The One Extra Check<\/h2>\n
\nthe files come through the web server? We should probably check the web server logs too.\u201d<\/em><\/p><\/blockquote>\n192.168.0.220 - chun [07\/Jun\/2026:00:04:19 -0700] \"MKCOL \/remote.php\/dav\/files\/chun\/Music\/OnTheSpot\/Tracks\/The%20Chorus%20of%20the%20Lion%20King%202%20-%20Simba's%20Pride\/[1998]%20The%20Lion%20King%202%20-%20Simba's%20Pride\/ HTTP\/1.1\" 201 1564 \"-\" \"FolderSync\"<\/code><\/pre>\nFolderSync<\/code><\/strong>.<\/p>\nThe Smoking Gun<\/h2>\n
\n
\n \nTime<\/th>\n Event<\/th>\n User-Agent<\/th>\n<\/tr>\n<\/thead>\n \n Jun 6 12:04<\/td>\n MKCOL + PUT \u2014 creates directories and uploads illegal-filename
\nfiles<\/td>\nFolderSync<\/td>\n<\/tr>\n \n Jun 6 13:14<\/td>\n DELETE \u2014 manually deleted via Nextcloud web UI<\/td>\n Edge browser<\/td>\n<\/tr>\n \n Jun 7 00:04<\/td>\n MKCOL + PUT \u2014 re-creates the same files<\/td>\n FolderSync<\/td>\n<\/tr>\n \n Jun 7 08:33<\/td>\n DELETE \u2014 manually deleted again<\/td>\n Edge browser<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n :<\/code> and *<\/code> in filenames, so FolderSync uploaded them without complaint. Worse, it created three variants<\/strong> of each illegal filename: one with the original character, one with a PUA Unicode replacement (U+F020 for :<\/code>, U+F021 for *<\/code>), and one with a dash. All three got uploaded every night.<\/p>\nHow Does an AI Agent Think?<\/h2>\n
\n
\nin layers: filesystem \u2713, database \u2713, web server\u2026 oh wait.<\/p>\nThe Bonus Discovery<\/h2>\n
datadirectory<\/code> config pointed to \/var\/www\/clouddata\/<\/code> \u2014 a ZFS dataset bind-mounted from the Proxmox host. But inside the LXC container, there was also an \/archive\/ncdata\/<\/code> directory on the root filesystem \u2014 a stale leftover from when Nextcloud used to run inside Docker.<\/p>\n\/var\/www\/clouddata\/<\/code>, and that\u2019s where FolderSync was uploading to.<\/p>\nfiles:scan<\/code> command finally reported zero OnTheSpot entries \u2014 and they stayed at zero.<\/p>\nLessons Learned<\/h2>\n
\n
\n