>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3626897. --> Reported by: [scotwith1t](https://www.drupal.org/user/658888) Related to !17 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>Since 3.1.8 (<a href="https://www.drupal.org/project/filebrowser/issues/3541722">#3541722</a>) the upload form stages files under <code>temporary://filebrowser/{nid}/</code> during the managed_file AJAX upload and copies them to the listing's folder when the user presses <em>Save Upload</em>. Those are two separate HTTP requests. On hosting where each web server has its own <code>/tmp</code> (Acquia Cloud Next, Pantheon, Platform.sh, any load-balanced setup without a shared temp directory) the save request often lands on a server that never received the upload, and the copy fails:</p> <blockquote><p>Failed to store example.pdf: File 'temporary://filebrowser/123/example.pdf' ('/tmp/filebrowser/123/example.pdf') could not be copied because it does not exist.</p></blockquote> <p>Two follow-on problems make this worse:</p> <ul> <li>The <code>$file-&gt;delete()</code> call sits after the copy inside the <code>try</code>, so the failed attempt leaves its <code>file_managed</code> row (status 0) pointing at the temporary URI. Every retry of the same file name is then rejected by core's file URI uniqueness constraint until cron removes the row after <code>temporary_maximum_age</code> (six hours by default): <em>The specified file example.pdf could not be uploaded. The file temporary://filebrowser/123/example.pdf already exists. Enter a unique file URI.</em></li> <li>The form still adds "Your Filebrowser upload completed successfully." after a failed copy, and nothing is written to the log, so the failure is easy to miss.</li> </ul> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <ol> <li>Run the site on two or more web servers that do not share <code>/tmp</code>, with the default <code>file_temp_path</code>.</li> <li>On a Directory Listing node, click <em>Upload</em>, choose a file, and press <em>Save Upload</em>.</li> <li>Repeat until the save request is served by a different server than the AJAX upload. The copy error above appears, the listing does not contain the file, and the success message appears as well.</li> <li>Upload the same file again: the widget itself now refuses it with the "already exists" message.</li> </ol> <p>On a single server the same failure can be forced by deleting the staged file from <code>/tmp/filebrowser/{nid}/</code> between the AJAX upload and pressing <em>Save Upload</em>.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <ul> <li>Stage uploads under <code>private://filebrowser-staging/{nid}/</code> when the private scheme is configured, falling back to <code>temporary://</code> when it is not. The private file system is shared between web servers wherever the site's own files are, and it is not served to browsers. Abandoned uploads are still cleaned up by cron, because the staged file entity keeps status 0.</li> <li>Delete the staged file entity whether or not the copy succeeded, so a failed save never blocks the next attempt.</li> <li>Only add the success message when no copy failed.</li> </ul> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <p>Review the merge request.</p> <h3 id="summary-user-interface-changes">User interface changes</h3> <p>The success message is no longer shown when a file failed to store.</p> <h3 id="summary-api-changes">API changes</h3> <p>None. <code>UploadForm</code> gains a protected <code>stagingBase()</code> method.</p> <h3 id="summary-data-model-changes">Data model changes</h3> <p>None.</p>