XPages File Upload Failing: The xspupload Temp Folder Wiped by Windows cleanmgr — Root Cause and Fixes (Including the 14.0 Fix)

There’s a way XPages uploads break that’s easy to blame on the wrong thing: the file upload control seems to do nothing — no error on the client, the page is fine, the file just doesn’t go up, so it’s tempting to blame the control or your own code. But check the server console and the Java exception points straight at the real culprit:

com.ibm.xsp.http.fileupload.FileUploadBase$IOFileUploadException:
Processing of multipart/form-data request failed.
…\notesXXXXXX\xspupload\upload_XXX_XXX.tmp (The system cannot find the path specified)

The community hit the same wall on 11.0.1 (StackOverflow: xpages file upload control does nothing in 11.0.1). If you’ve met this and ended up keeping it alive by “cycling HTTP up and down every night” — this piece is about what that actually is, and the fixes that beat a nightly restart.

TL;DR

• Root cause: XPages uploads use a temp folder named xspupload under the OS Temp dir (a path like …\notesXXXXXX\xspupload). If that folder goes missing, uploads fail and the console throws IOFileUploadException … The system cannot find the path specified.
• It’s a defect: per KB0106430, before 14.0 Domino does not auto-recreate the folder once it’s deleted; it’s fixed in Domino 14.0 (SPR ASHECU5DHW).
• Why the folder disappears: a common culprit is Windows Disk Cleanup cleanmgr.exe, which deletes the temp files while Domino is running, taking xspupload with them (KB0078234).
• Fixes: manually recreate the xspupload folder (instant, no restart, no downtime) → or restart the HTTP task → point Notes_TempDir out of the system Temp to cut the source → disable the cleanmgr scheduled task → self-heal in code on startup → upgrade to 14.0 and be done.

Symptom and root cause: the xspupload temp folder is gone

Start with how the defect is officially described. KB0106430 (applies to Domino 9.0.x and later) is clear: when you upload via the file upload control in XPages, Domino creates an xspupload temp folder under the OS Temp dir (e.g. notesXXXXXX\xspupload); delete that xspupload folder and the attachment won’t upload, with the console showing:

com.ibm.xsp.http.fileupload.FileUploadBase$IOFileUploadException:
Processing of multipart/form-data request failed.
C:\Windows\TEMP\notesXXXXXX\xspupload\upload_XXX_XXX.tmp (The system cannot find the path specified)

The KB also spells out the “should, but doesn’t” behavior: Domino ought to recreate the folder automatically when it’s missing — but (before 14.0) it doesn’t, so once the folder is deleted, uploads jam. The KB’s workaround is a single line: “Recreate ‘xspupload’ folder.” This defect (SPR ASHECU5DHW) is fixed in Release 14.0: from 14.0, Domino recreates the folder when needed.

Why the folder disappears on its own: Windows cleanmgr

The folder was fine — so why does it vanish? The most common culprit is Windows’ built-in Disk Cleanup, cleanmgr.exe. KB0078234 (applies to Domino 9.0.x, 10.0.x, 11.0.x and later) nails the cause:

“Windows cleanmgr.exe task deleted all the temp files from the Domino temp folder. These include temporary application files as well which will cause all the applications to fail.”

That is: the cleanmgr scheduled task, while Domino is still running, clears out the Domino temp folder — taking the in-use xspupload with it — so every app’s uploads break. The console shows the same IOFileUploadException … The system cannot find the path specified as KB0106430; this one just names who deleted it.

You might ask: isn’t cleanmgr something you launch by hand — how does it delete on its own? Because Windows ships a scheduled task called SilentCleanup (\Microsoft\Windows\DiskCleanup\SilentCleanup) that runs cleanmgr.exe /autoclean silently as SYSTEM, triggered automatically when the system drive is low on free space — nobody clicks anything. Newer Windows (10, version 1703 and later) also adds Storage Sense for automatic cleanup. This also explains a common puzzle: why the same Domino version (the defect goes back to 9.x) is fine on some boxes but suddenly starts failing on others — what changed is usually not Domino but a move to a newer Windows with more aggressive automatic cleanup, or a disk filling up enough to cross SilentCleanup’s low-space threshold, at which point the OS starts deleting the in-use temp folder. To pin down the culprit in your environment, KB0078234 suggests using Process Monitor to catch what deleted the file.

Fixes: from “instant recovery” to a real cure

One illness, several medicines — grouped as “instant recovery,” “cut the source,” and “permanent cure.”

1. Manually recreate the xspupload folder (no service interruption). When something breaks in production and you can’t just restart the service, this is the fastest move — and it’s exactly the implementation of KB0106430’s workaround, “Recreate ‘xspupload’ folder.”:

• Read the path out of the console error (e.g. …\notes74483D\).
• Go to that path by hand and check whether an xspupload folder is there.
• If not, manually create a folder named xspupload.

Recreating it usually restores uploads immediately — no HTTP restart, no service interruption — which is exactly what you want when you can’t restart in production.

2. Restart the HTTP task. KB0078234 says it plainly: “Restarting the HTTP task will recreate the application when it is loaded again and will workaround the issue.” — restarting HTTP also recreates the folder. The common “cycle HTTP up and down every night” band-aid is exactly this: it works, but it interrupts service and only puts the folder back before the next cleanmgr run — treating the symptom.

3. Move the temp dir out of the system Temp (Notes_TempDir) — cut the source. KB0078234’s second workaround: “create a new folder and use the notes_tempdir parameter to point tmp files to that folder.” Make a folder and add or change this parameter in Notes.ini:

Notes_TempDir=C:\DominoTemp

The benefit: a custom path isn’t scanned by Windows’ system cleanup tasks, so Domino’s temp files don’t get deleted by cleanmgr — cutting the problem off at the source. (Notes.ini parameters are case-insensitive.)

4. Disable the cleanmgr task outright. If you’d rather not touch the Domino side, the KB offers it too: disable the cleanmgr.exe scheduled task on the Windows server. Remove the source and the folder stops being deleted.

5. Self-heal in code: check on startup, recreate if missing. Once you know the root cause, the app can look after itself. The community approach is to check, at the XPages app’s startup (e.g. onStart), whether the upload temp folder exists and mkdirs it (plus read/write/execute permissions) if not:

import java.io.File
def tmpDirPath = context.getServletContext()
        .getInitParameter('com.ibm.xsp.upload.tmp.dir') ?: 'xspupload'
def tmpDir = new File(tmpDirPath)
if (!tmpDir.exists()) {
    tmpDir.mkdirs()
    tmpDir.setExecutable(true, false)
    tmpDir.setReadable(true, false)
    tmpDir.setWritable(true, false)
}

The idea is simple: test whether the folder exists, recreate it if not. One caveat: the real xspupload path lives under NOTES_TEMPDIR (or the system %TEMP%) as notesXXXXXX\xspupload, and the snippet above is one community way to hang the recreate on the app lifecycle — before adopting it, confirm in your environment that the path it resolves to really is that upload folder.

6. The permanent cure: upgrade to 14.0. This was a defect all along, and from 14.0 Domino recreates the folder automatically (KB0106430). If you can upgrade, you stop playing cat-and-mouse with cleanmgr.

Wrap-up

An XPages upload that “does nothing” is nine times out of ten not a broken control — it’s that the xspupload temp folder it needs got wiped, often by Windows cleanmgr sweeping it up while Domino ran. The order of diagnosis: recognize the IOFileUploadException … The system cannot find the path specified in the console to confirm the illness; short term, when you can’t restart, manually recreate the xspupload folder to recover instantly; medium term, cut the source with Notes_TempDir or by disabling cleanmgr; and if you can upgrade, go to 14.0 for the real fix. This is the flip side of a prerequisite the series opener noted for the File Upload Control — the server needs a working temp directory for attachments to land in; this piece is the full troubleshooting for when that directory goes wrong.

← Back to all posts