Skip to main content
Question

FME Flow 2024 publish a workspace not working


tfn_wv
Contributor
Forum|alt.badge.img+2

Dear Community,

i am experiencing a strange behavior from our FME Server when uploading/publishing a FME Desktop workspace in FME Server.

Previously, it was possible to publish workspaces from FME Desktop to FME Server.

Recently, publishing from FME Desktop is no longer possible, nor is it possible to upload workspaces to FME Server via the Web UI.

I only receive very little information about the error in FME Desktop ,also with the debug logging.

The following excerpt from the log:

Successfully retrieved service properties.

Retrieving service parameters for ‘geodatabase_sde2none.fmw’...

No service parameters found.

Uploading as ‘geodatabase_sde2none.fmw’...

Publish failed - FME Flow encountered an error.

When I upload a workspace in FME Server via Web UI, I get the following messages in the network console of the Browser:

Get Call <FME-Server-URL>/repositories/{repository}/items/{item}

returns a 404 Not Found status code and 

{

"reason": "missing",

"what": "geodatabase_sde2none.fmw",

"message": "The repository item \"geodatabase_sde2none.fmw\" does not exist"

}

The Get Call: <FME-Server-URL>/fmeapiv4/repositories/{repository}/items/upload

returns a 400 Bad Request status code and

{

"message": "The request body type was unexpected. Was expecting multipart/form-data."

}

I have already tried uploading with the Admin account and a workspace from FME Hub, but i also got the error.

I have already restarted the FME server, which unfortunately did not solve the problem.

Currently we use FME Desktop Version: FME 2024.0.1.0
The FME Server has the version: FME Flow 2024.0.1


I am so confused that this is not working, which had worked before.

Did someone had similar problems in the past?

Kind regards,

Tim

 

10 replies

virtualcitymatt
Celebrity
Forum|alt.badge.img+45

definitely strange - The first 404 you’re seeing if just FME Server checking if the workspace already exists - that one’s normal. 

The second call you’ve listed is the call which actually uploads the file. 

In the developer tab you should be able to check the request body / payload.

For me I see the following:

 


If I click click the View source button in the From Data section it’s a bit of metadata and then the workspace: e.g.,

------WebKitFormBoundarye4ImtQjUjHYElc8V
Content-Disposition: form-data; name="files"; filename="Undefined_macro_Issue.fmw"
Content-Type: application/octet-stream

#! <?xml version="1.0" encoding="UTF-8" ?>
#! <WORKSPACE # Command line to run this workspace:
#          "C:\Program Files\FME_23631\fme.exe"  Undefined_macro_Issue.fmw
# --FME_LAUNCH_VIEWER_APP "YES"
#
…...

The Response to this call is the metadata from the workspace. 

Have you tried uploading any other workspaces? Could be some really weird specific issue with the workspace


tfn_wv
Contributor
Forum|alt.badge.img+2
  • Author
  • June 24, 2025

I have exactly the same results like you under the “View source” button in the Form Data of the payload.

Content-Disposition: form-data; name="files"; filename="excel.fmw" Content-Type: application/octet-stream

Yes i tried serveral Workspaces, just a simple excel reader for example and its still not working.

I just saw now that there is a line in the Payload form data:
#!A0_PREVIEW_IMAGE="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAByCAIAAADyJhCmAAAACXBIWXMAAA7EAAAOxA…

Maybe this causes the error?


virtualcitymatt
Celebrity
Forum|alt.badge.img+45
tfn_wv wrote:

I just saw now that there is a line in the Payload form data:
#!A0_PREVIEW_IMAGE="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAByCAIAAADyJhCmAAAACXBIWXMAAA7EAAAOxA…

Maybe this causes the error?

No it’s unlikely to be that - I see the same thing. 

Certainly I see now in your original post that you mentioned trying multiple workspaces. I guess the server is the most likely issue, however, to make sure have you tried publishing from another machine at all? 

Are you going through a proxy at all to FME Server, it could be somehow the proxy is messing up something if so?

My next step would be to look into the FME Server logs to see if there is anything going on there. 

Have you been able to upload to a resource folder? 

If you can’t publish and can’t upload at all to the server it may suggest a permissions issue or something like that on the server.

Have your tired to restart the whole machine running FME Server? or just the FME Server service itself?    


ebygomm
Influencer
Forum|alt.badge.img+43
  • Influencer
  • June 24, 2025

I’ve seen a similar issue before when an FME workspace had been deleted from the fileshare but was still showing via the user interface.

 

Is your fileshare on the same machine as server or elsewhere?


tfn_wv
Contributor
Forum|alt.badge.img+2
  • Author
  • June 24, 2025
virtualcitymatt wrote:
tfn_wv wrote:

I just saw now that there is a line in the Payload form data:
#!A0_PREVIEW_IMAGE="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAByCAIAAADyJhCmAAAACXBIWXMAAA7EAAAOxA…

Maybe this causes the error?

No it’s unlikely to be that - I see the same thing. 

Certainly I see now in your original post that you mentioned trying multiple workspaces. I guess the server is the most likely issue, however, to make sure have you tried publishing from another machine at all? 

Are you going through a proxy at all to FME Server, it could be somehow the proxy is messing up something if so?

My next step would be to look into the FME Server logs to see if there is anything going on there. 

Have you been able to upload to a resource folder? 

If you can’t publish and can’t upload at all to the server it may suggest a permissions issue or something like that on the server.

Have your tired to restart the whole machine running FME Server? or just the FME Server service itself?    



I tried publishing from my local Desktop PC, which is not the same machine as the FME Server running on.
Unfortunaltey i didnt try to upload from another machine (from another collegue).

The proxy could be the problem maybe.

I checked the logs already in FME Server. I didnt found there something about the error in the upload process. Or am i just looking in the wrong log file directory?

I also thought about the permissions in the filesystem of FME Server maybe.​​​​​​



 


tfn_wv
Contributor
Forum|alt.badge.img+2
  • Author
  • June 24, 2025
virtualcitymatt wrote:
tfn_wv wrote:

I just saw now that there is a line in the Payload form data:
#!A0_PREVIEW_IMAGE="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAByCAIAAADyJhCmAAAACXBIWXMAAA7EAAAOxA…

Maybe this causes the error?


Have your tired to restart the whole machine running FME Server? or just the FME Server service itself?    


I restarted the whole FME Server Services but not the machine itself.


tfn_wv
Contributor
Forum|alt.badge.img+2
  • Author
  • July 11, 2025

Thanks everyone for the support.

We solved the problem. :)

The problem was caused due to wrong tomcat user Directory and Account Permissions
to the wrong tomcat folder(s).

These permissions has been reset in the past. (Maybe this happened with an update).

After we set these it worked fine again.

This link helps: https://docs.safe.com/fme/html/FME-Flow/ReferenceManual/Directory-Account-Permissions.htm

Kind regards,

Tim


davidwilton
Contributor
Forum|alt.badge.img+1
  • Contributor
  • July 28, 2025

We got this issue in FLOW 2025.1.

I could see in the catalina.2025-07-24.log (in the FlowSystemShare\resources\logs\tomcat)  that the temp dir was set to 

24-Jul-2025 09:42:20.265 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=\\share\FME\FlowSystemShare\dev/resources/system/temp\tomcat

 

and later in the log file

sun.jersey.server.impl.application.WebApplicationImpl._initiate Initiating Jersey application, version 'Jersey: 1.19 02/11/2015 03:25 AM'
24-Jul-2025 09:43:09.715 WARNING [Catalina-utility-3] com.sun.jersey.multipart.impl.MultiPartReaderClientSide.createMimeConfig Cannot create temporary files. Multipart attachments will be limited to 4096 bytes.
    java.io.IOException: The system cannot find the path specified

 

All I had to do was create the ‘tomcat’ directory. What I don’t understand is a) why didn’t FME just create this? b) in 

"D:\Program Files\FMEFlow\Utilities\tomcat\webapps\fmeserver\WEB-INF\conf\propertiesFile.properties"

TEMPORARY_DIRECTORY = //share/Applications/FME/FlowSystemShare/dev/resources/system/temp/upload

 

This seems like an FME bug in the new version?


fmegisuser
Participant
Forum|alt.badge.img+1
  • Participant
  • September 23, 2025

Thanks ​@davidwilton - we just had the same thing happen. Could not publish FME workbenches or upload any files to FME Flow.
As you suggested, I looked in the tomcat\catalina.log for this path “Djava.io.tmpdir=”
It was set to “C:\ProgramData\Safe Software\FMEFlow\resources\system\temp\tomcat”
What I found that the tomcat folder was missing and there was the message in the log files was the same as yours

All I needed to do was create the tomcat folder and restart FME Flow and it worked.

Not sure why the folder was missing?


davidwilton
Contributor
Forum|alt.badge.img+1
  • Contributor
  • September 23, 2025
fmegisuser wrote:

Thanks ​@davidwilton - we just had the same thing happen. Could not publish FME workbenches or upload any files to FME Flow.
As you suggested, I looked in the tomcat\catalina.log for this path “Djava.io.tmpdir=”
It was set to “C:\ProgramData\Safe Software\FMEFlow\resources\system\temp\tomcat”
What I found that the tomcat folder was missing and there was the message in the log files was the same as yours

All I needed to do was create the tomcat folder and restart FME Flow and it worked.

Not sure why the folder was missing?

I submitted this to save who could not recreate. I had the same issue in DEV, TEST and then predictably when I deployed the third time no issue. Glad I’m not the only one getting it.


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings