KNIME server read Excel file Execution Fail Direct access to the local file system is not allowed on KNIME

Hi could anyone assist me in understanding why I am unable to execute my KNIME workflow off the KNIME web portal.

I have created Components which get user input parameters successfully off the web portal, but as the workflow reaches the read exel file, the workflow Fails with the following error:
" Excel Reader (XLS) 5:192:179 - ERROR: Execute failed: Direct access to the local file system is not allowed on KNIME Server.
Excel Reader (XLS) 5:192:184 - ERROR: Execute failed: Direct access to the local file system is not allowed on KNIME Server.
I have tried setting up the “Read File From” option on the Excel File reader Node to URL and passed the URL variable but I still yield the same error.

I require this workflow to be used by teams whom have files saved on the local drive and I would like the user to be able to go into the web portal upload their file from there local storage and successfully execute the workflow without the hassle of saving the files to the workspace.

Any assistance would be greatly appreciated. I have attached screenshots of a basic test workflow that attempts the same action but also fails.


Hello @Miguel_n11,

check bottom two topics for more info:


1 Like

This has still not helped the error.



Hi Miguel,

you could set the option


within the preferences.epf or the executor.epf file if using server managed preferences (default on Server 4.11.) that allows the otherwise blocked local file system access on the server.


Or you could use a Temp dir to store the uploaded file within the workflow repository like mentioned in this example:



Hi Michael,

Thanks for this. We have set the instance local fs access option to true, but still receive an error. Not sure why? I will try use your alternative, Thanks a mill.



Hi Miguel,

just want to ask quickly, if you could solve your issue already?

Thanks in advance,

1 Like

Hi KNIME Team,

We recently upgraded our KNIME medium server edition to 4.13.1. Post the upgrade workflows are unable to access local file system folders resulting error “The directory ‘xxxx’ does not exist and must not be created due to user settings”.

We did set the configuration (/instance/org.knime.filehandling.core/allow_local_fs_access_on_server=true) in “executor.epf” file located in the “…\workflow_repository\config\client-profiles\executor\executor.epf” but that did not solve the problem.

Is there anything else we need to check that out?

1 Like

Hi @Nathmal,

Welcome to the KNIME community.

Could you please name the version you are coming from and the node, you tried accessing the file with, is it the Excel Reader? How are the folders addressed, via “file:/abc/def”?

Things I would suggest to check would be the configuration to use the “executor” profile for configuration either within the knime.ini of the executor or within its service definition. Please check also, if the mentioned directory/folder is accessible via the owners of the KNIME Server/Executor services.


Thank you for your response.

I believe you are referring the Server version then I can think it was 4.12.1. However, I do remember adding configuration of /allow_local_fs_access_on_server=true in the executor.epf in my last installation and it was working fine after the change.

We are getting this error while using CSV Writer Node and its a write operation to local file system. The folder structure looks like this D:.…\Filename.txt.

My executor profile setting looks like this.

do you mean adding these configuration to be added in Knime.ini file?

There have not been any changes in the permission level of the users and we noticed this issue as soon as the upgrade was done.

I assume that the executor profile is not properly applied on your KNIME Server installation causing this issue.

You would be able to check this accessing the following file:


If this doesn’t contain the /instance/org.knime.filehandling.core/allow_local_fs_access_on_server=true line the executor.epf settings are not applied properly.

Could you please elaborate which OS you are using and how the executor is started (via service or script)?


I found one copy of the “combined-preferences.epf” on my server and I can confirm that I am see the local file system setting set to “True” to the /.metadata/.plugins/org.knime.product/combined-preferences.epf file. I am listing down the actual content of the file you mentioned for reference.

#Wed Aug 04 08:41:59 GST 2021

I am using Windows Server 2019 Datacenter as OS. This server is hosting the KNIME Medium server and executor is running via Windows Service and i can see that in services.msc.

The first line of the file indicates that it was created at #Wed Aug 04 08:41:59 GST 2021. This file is created on each restart of the KNIME Executor. Does this match the last restart of the KNIME Server after the update? If not, there seems to be something wrong with applying the settings of the executor.epf. Have you restarted the KNIME Executor? This is needed to get the added configuration line applied.

Could you please check your install-executor-as-service.bat?

Did you edit the following line, deleted the REM? It might be necessary to change the URL too, depending on your setup.

If you haven’t done it please edit this line, save the script. Run remove-executor-as-service.bat as admistrator and reinstall it via install-executor-as-service.bat so that the changed settings are applied to the Executor service.


I just realized that the there is one more copy in my server with named '/combined-preferences.epf` file and thats why you have noticed that it is not updated with date as september but in Aug.

I further followed your instruction and removed removed the Knime Executor and reinstall the executor as service using install-executor-as-service.bat, the combined-preferences.epf file does not have the org.knime.filehandling.core/allow_local_fs_access_on_server=true flag that means as per your previous post, this setting is not getting applied. I am now listing the actual content of the combined-preferences.epf for your reference.

#Wed Sep 15 19:27:20 GST 2021

Given this new finding, could you please suggest, why it is not getting applied ?

Additionally, I double checked the execetor.epf file and i can still see that the flag for local file system is still set to true. This is the actual content of executor.epf.


Before removing and re-installing the KNIME Executor Service you have to edit the in my last post mentioned line. I just saw, that the line wasn’t included in my post, sorry for that.

REM SET "KNIME_EXECUTOR_PROFILES=-profileLocation http://localhost:8080/knime/rest/v4/profiles/contents -profileList executor"

Please delete the REM to activate this line and eventually edit the URL to match the KNIME Servers one. If your Executor is running on the same machine as the KNIME Server localhost should be sufficient.

After Editing please remove and install the Executor service again.

I am sorry for the inconvenience.

Thanks for your response. I tried it but unfortunately the error while writing does exists. For your reference, I am now listing the actual content on the install-executor-as-service.bat file.

@echo off
SET “KNIME_EXECUTOR_WORKSPACE=C:\knime\executor-workspace”
SET “KNIME_EXECUTOR_MSGQ=amqp://knime:20knime16@localhost/”
SET “KNIME_EXECUTOR_PROFILES=-profileLocation https://localhost:8443/knime/webportal/ -profileList executor”

However, one improvement now is that the combined-preferences.epf file now has the flag set as we expected. But the error still persists.

#Wed Sep 15 21:11:04 GST 2021

1 Like

Hi, Update:

Have restarted the tomcat server and then restarted the Knime executor from services.msc, and with this, I am able to execute the WF directly from the server using web portal and its now writing to local file system on server/hard drive.

Question: when I am executing the same WF connected to the server mount point from the Analytics platform from the development computer, the error still exists. therefore, I think this is something to do with the access of users/permission?

To counter my understanding, I logged to the web portal using the developer’s credentials and re-run the same WF and it worked this time as well ie. writing to local file system works. So my understanding is that when i execute the WF from the web portal it is working now but when i execute the same WF from the analytics platform, it still unable to write to the server. I will do some more analysis on this and update here. In the meantime, please let me know if you think i am missing something here.

1 Like

Hi @Nathmal , this is usually indeed related to access permission. But also, you may be looking at 2 different locations here.

When you run the WF from your local Knime AP, how exactly are you writing to the server? Even though you open the WF that’s on the server, you are opening it from your local Knime AP, so if you reference to any local path in the WF, it’s referencing to local path of where your local Knime AP is, not the knime server.


Thanks @bruno29a for explaining the differences in opening Server Workflows on the KNIME Analytics Platform (KAP). I just want to add some details on it:

If you open a KNIME Server workflow via double click it opens locally on the KAP, a yellow warning bar is shown above the opened workflow. It will use the local ressources.

If you want to execute or inspect a workflow running on KNIME Server you can install the Remote Workflow Editor Extension. Then you can choose Open → as new job on server via right click on a KNIME Server Workflow. It will be loaded on the KNIME Executor and shown in the workflow editor of the KAP. A purple information bar is shown above the open workflow to indicate that. Source

If you want to access the KNIME Servers File System via a local running workflow you can use the KNIME Server Connector for this. But this is restricted in the file system access, only workflow repository files are shown.


Dear Team,

Thank you for your valuable response. I managed to resolved the issue. Its working fine now as expected. Thank you once again.