Slack File Upload not working with Binary File option

[brey31]

Describe the problem/error/question

When using the Slack Upload File node with the Binary File option enabled, I receive the error, "ERROR: Slack error response: “no_file_data”.

What is the error message (if any)?

ERROR: Slack error response: “no_file_data”

Please share your workflow

Share the output returned by the last node

ERROR: Slack error response: “no_file_data”

Information on your n8n setup

• n8n version: 1.24.1
• Database (default: SQLite): SQLite
• n8n EXECUTIONS_PROCESS setting (default: own, main): default
• Running n8n via (Docker, npm, n8n cloud, desktop app): docker
• Operating system: debian

[brey31]

I can’t edit the original post, but this is a better example of my workflow.

[giulioandreini]

Hi @brey31
welcome to the n8n community!

If your previous node outputs a binary file, you don’t need the Convert to/from binary data node in the middle. So your workflow should be something like this:

Let me know if that helps and it works for you.
All the best

[brey31]

Thanks for the quick response @giulioandreini. Unfortunately this does not resolve my issue. The same error is returned.

I’ve tried to recreate the functionality provided in the Slack Upload File node with a standard HTTP Request node, and I get the same response returned from the Slack API. Slack is expecting a multipart/form-data request with a file parameter, but it seems like the request isn’t being formed correctly.

Webhook.site - Test, process and transform emails and HTTP requests

[giulioandreini]

Hi @brey31
sorry to hear you still have the problem.

In the HTTP Request node you can try to use the “Body Content Type” → “n8n Binary File” and see if that works, this is often better if you send an image as body parameter.

A couple of questions about the Slack node:

1. which type of connection are you using? Oauth or access token?
2. are you sending the image to a private channel, public channel, or to a user as a direct message?

Asking so that I can reproduce a similar scenario.
Best

[brey31]

@giulioandreini That seems to work better - Webhook.site - Test, process and transform emails and HTTP requests

The issue now is that I can’t include other form fields when using the n8n Binary File content type in conjunction with the HTTP Request node.

To answer your questions:

1. I’m using an access token for authentication.
2. When using the Slack node, I am sending it to a channel using a string formatted as such: {{ [“XXXXXXXXXX”] }}

[giulioandreini]

@brey31
yes, unfortunately if you select the “n8n Binary File” option in the HTTP Request node it is not possible to set other parameters (this is under our radar and something we’ll improve).

I double-checked again using the settings you suggested and it works on my side, I copy my workflow here so that you can double-check:

A few notes here:

1. I tested it both with the User OAuth and Bot User OAuth tokens, and worked with both.
   
   
2. Be sure to add the scopes files:read and files:write to your token

Let me know if this helps
Best

[brey31]

I’m still not seeing a successful post. My bot does have the read and write scopes and I’ve successfully used PostMan to upload a file using the same token. My Slack Upload node’s configuration looks to be the same. If it helps, I am running 1.24.1.

I’ve taken a screenshot of the input and output:

[giulioandreini]

@Jon could this be related to the type of n8n deployment? (docker in this case)
A very similar workflow seems to work correctly for me (on Cloud) but fails for @brey31

[Jon]

Yeah it could be down to the deployment type, @brey31 can you try setting the N8N_DEFAULT_BINARY_DATA_MODE environment variable to filesystem if it isn’t already and let me know if that helps.

[brey31]

@Jon that seems to have resolved the issues I’ve been having. Is it generally recommended to use filesystem or s3 for binary files?

[Jon]

Hey @brey31,

If you use Filesystem it will keep the binary data out of memory which is better for performance / resource usage.

[Martin_CMS]

We did run into the same issue and I can confirm that changing N8N_DEFAULT_BINARY_DATA_MODE to filesystem did help here.

Interestingly, this only stopped working with the default option a few versions ago (I do think it was 1.24, but am not 100% sure)