"Can not write to path …/tmp/: java.io.IOException: Separation boundary was not specified" in Import Sets / System Logs — Why it appears and when it can be ignoredIssue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } System logs show “Separation boundary was not specified / Can not write to path …/tmp/” during Data Source/Import Set actions due to multipart parsing of a non-multipart request. You are unsure of what causes this and whether you need to be concerned due to these errors. Symptoms<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Frequent system log entries similar to: “Can not write to path /glide/nodes/_/bin/../tmp/: java.io.IOException: Separation boundary was not specified”Stack trace includes: com.glide.ui.multipart.MultipartParser.<init>(MultipartParser.java:186)com.glide.ui.SysAttachment.getMPP(...)com.glide.ui.SysAttachment.writeFromRequest(...)com.glide.processors.ImportProcessor.writeInputFileWithCSRFCheck(...)com.glide.processors.ImportProcessor.process(...) Typical triggers: Clicking “Test Load 20 records” or “Load All Records”Running Import Set operationsUsing connectors / integration jobs (e.g., SGC-related imports)Calling /sys_import.do through automation or scripts Facts<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } The exception text “Separation boundary was not specified” comes from the multipart parser and indicates missing multipart boundary information in Content-Type.Multipart boundaries exist only when requests are made as multipart/form-data uploads; they are required for parsing multiple parts (file + metadata).The presence of “/tmp/” in the log line is not sufficient to conclude a filesystem permission issue. It is a generic wrapper logged by import/attachment handling when input file creation fails for any reason, including parsing failures.Many cases show no functional impact: rows still load, transforms still run, and data progresses correctly.In other cases, the same log message may coincide with a real functional defect (e.g., records stuck in Loaded, no rows created), which should be treated separately (often PRB-linked). Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } All Releases Cause<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Primary root cause (most common / benign scenario) The platform attempts to parse an incoming import request as multipart in order to support file upload behavior. When the request is not actually multipart, or when the Content-Type header does not include the required boundary=..., MultipartParser throws: java.io.IOException: Separation boundary was not specified The import processor logs this under a generic “can not write to tmp path” wrapper, even though the underlying failure is request parsing, not OS write permissions. Alternate/related root causes (actionable scenarios) If functional failures are noted, the log may be an accompanying symptom rather than the sole cause of the issue. Investigate the following by reaching out to ServiceNow Technical Support: Known platform ingestion defects (e.g., PRB1755497 patterns) where rows don’t progress beyond Loaded.Unsupported UI actions in certain configurations (e.g., “Test Load / Load All” not supported when parallel loading is enabled for some connectors/apps).Caller/integration sending malformed multipart (custom scripts, proxies, WAF rewriting headers, etc.).True filesystem issues only if the underlying exception indicates permission/space (see Resolution section for how to distinguish). Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 1) Determine if it can be ignored (no functional impact) This error can be treated as log noise and safely ignored when all of the following are true: Import set rows are created successfullyRows progress through Loaded → Transforming → Processed as expectedYou does not observe missing data, stuck imports, or failed transformsThe underlying exception is specifically “Separation boundary was not specified” from MultipartParser (not an OS-level write error) Why it can be ignored:The exception occurs during an attempted multipart parse of a request that is not multipart (or lacks a boundary). In these scenarios, the platform proceeds with the workflow path that does not require multipart parsing, and no data corruption or persistence failure occurs. This message indicates the platform attempted to interpret the request as a multipart upload, but no multipart boundary was present. When imports are loading and processing normally, this log entry does not represent a filesystem permission issue and does not impact functionality. 2) When NOT to ignore (functional impact present) Do not classify as ignorable if any of the below apply: “Test Load 20 records” completes, but no import set rows are createdImport set rows are present but stuck in Loaded and never progressScheduled import jobs do not bring data or transforms never occurImpact is observed on missing/partial data, stalled ingestion, etc. In these cases: Check whether the scenario matches known ingestion/connector PRBs (e.g., PRB1755497 patterns).Apply documented workarounds (if applicable) and align the case with the correct PRB/KE article. 3) How to confirm a REAL filesystem permission issue (rare) Only treat as filesystem permissions/storage when the underlying exception indicates it, e.g.: Permission deniedAccessDeniedExceptionRead-only file systemNo space left on deviceFileNotFoundException when writing the tmp file If those appear: Validate node disk space / permissions / tmp mount behaviorEngage infra/DC ops if confirmed on ServiceNow-hosted nodes (customer-side action is limited) 4) Recommended troubleshooting checklist (internal) Use this short checklist to quickly classify: Check stack origin If stack starts at MultipartParser.<init> with boundary error → likely parsing/multipart mismatch. Check outcome Did rows load and transform? If yes → likely ignorable. Check request nature (if access logs available) If request is navigation-like (redirect into /sys_import.do, GET/302 patterns) → supports “not multipart”. Check for PRB/known issue symptoms Rows stuck in Loaded / no transform progression → treat as actionable and correlate to ingestion PRBs.