Skip to main content
SmrithiG1
Level 3
Oct 13, 2026 8:00 AM UTC
Solved

How to create a file on shared location outside AEM, on a separate server

Hi,

We are using aem 6.5 and aem forms as well. (running on windows servers)

we have requirement from client to generate a file and not to save it on dam, instead if it can be copied to an external shared folder location. 

Do you know if this is a good practice to save a file on shared location from Production and how to achieve this (with respect to permissions) 

I have seen this link: Share assets using a link | Adobe Experience Manager, but I am not sure if this will be accepted, as the older systems are already using the shared location to access the file.

social_portfolio81dbAccepted solution
Level 2
Oct 13, 2026 3:25 PM UTC

​@SmrithiG1 ,

Yes, writing to a shared folder is acceptable when legacy systems already read from it, as long as you don’t write to the share inside the form submit request.

The “Share assets using a link” feature won’t help. It only creates download URLs for assets already in DAM and never puts a file on a share.

How I’d do it on 6.5

  1. Use Invoke an AEM Workflow as the adaptive form submit action. The data XML, attachments and DoR PDF then sit under the workflow payload.
  2. Add a custom process step that queues a Sling job. The job writes the file with java.nio.file to a UNC path (\\fileserver\share\folder), so retries are handled if the file server is down.
  3. Write to a .tmp file first, then rename it with Files.move(..., ATOMIC_MOVE), so the legacy system never reads a half-written file.
  4. Use deterministic file names (for example the submission ID), because Sling jobs run at-least-once.
  5. Keep the target path in OSGi config.

If you are on AEM Forms JEE, the Workbench File Utilities → Write Document operation does this without custom code.

Permissions

  • Use UNC paths only. Windows services can’t see mapped drives.
  • Run the AEM service as a dedicated domain account or gMSA, not LocalSystem.
  • Give that account Change (share) and Modify (NTFS) on the one target folder only.
  • Open TCP 445 only between the AEM host and the file server, and keep it off publish.
  • Don’t hard-code credentials.

Share vs cloud storage (Azure Blob / S3)
Cloud storage is usually the better long-term target. It removes the SMB and domain dependencies, gives you better durability, access control and auditing, and works the same wherever AEM runs. The catch here is that your older systems already read from the share, so moving to Blob or S3 means changing every consumer or adding a sync job back to the share. For the current requirement, the share is the pragmatic choice. A good middle path is to have AEM post to a small REST service next to the file server that writes locally. You can then swap the backend to cloud storage or SFTP later without touching AEM.

Hope this helps!

View in thread

3 replies

social_portfolio81dbAccepted solution
Level 2
Oct 13, 2026 3:25 PM UTC

​@SmrithiG1 ,

Yes, writing to a shared folder is acceptable when legacy systems already read from it, as long as you don’t write to the share inside the form submit request.

The “Share assets using a link” feature won’t help. It only creates download URLs for assets already in DAM and never puts a file on a share.

How I’d do it on 6.5

  1. Use Invoke an AEM Workflow as the adaptive form submit action. The data XML, attachments and DoR PDF then sit under the workflow payload.
  2. Add a custom process step that queues a Sling job. The job writes the file with java.nio.file to a UNC path (\\fileserver\share\folder), so retries are handled if the file server is down.
  3. Write to a .tmp file first, then rename it with Files.move(..., ATOMIC_MOVE), so the legacy system never reads a half-written file.
  4. Use deterministic file names (for example the submission ID), because Sling jobs run at-least-once.
  5. Keep the target path in OSGi config.

If you are on AEM Forms JEE, the Workbench File Utilities → Write Document operation does this without custom code.

Permissions

  • Use UNC paths only. Windows services can’t see mapped drives.
  • Run the AEM service as a dedicated domain account or gMSA, not LocalSystem.
  • Give that account Change (share) and Modify (NTFS) on the one target folder only.
  • Open TCP 445 only between the AEM host and the file server, and keep it off publish.
  • Don’t hard-code credentials.

Share vs cloud storage (Azure Blob / S3)
Cloud storage is usually the better long-term target. It removes the SMB and domain dependencies, gives you better durability, access control and auditing, and works the same wherever AEM runs. The catch here is that your older systems already read from the share, so moving to Blob or S3 means changing every consumer or adding a sync job back to the share. For the current requirement, the share is the pragmatic choice. A good middle path is to have AEM post to a small REST service next to the file server that writes locally. You can then swap the backend to cloud storage or SFTP later without touching AEM.

Hope this helps!

Translate
    SmrithiG1Author
    Level 3
    Oct 14, 2026 9:00 AM UTC

    @social_portfolio81db, Thank you for your detailed response.

    Currently we are using windows machine account, and for AEM application to write to a shared location, we need read, modify permissions for these windows user accounts on the specific shared location.

    As you have suggested cloud storage is something we can consider for future. Thanks again.

     

     

    Translate
    social_portfolio81db
    Level 2
    Oct 14, 2026 9:49 AM UTC

    ​@SmrithiG1 ,

    Glad that my response helped. Please try the cloud storage option and let know if there are any blockers.

    Regards,

    Santhosh

    Translate
      Terms & ConditionsAccessibility statement

      Loading footer...