Hi,
I’m having the same issue but using an absolute path to the server file. As the author mentioned, the file is read OK into an Excel Reader node but this same node in the same WF doesn’t work from the server itself. The file resides in the same server. Looks like my local PC has access to the path but not the server instance itself (access to itself)…
Any help/thoughts appreciated!
Hi @szhu -
(I made your post into a separate topic so it doesn’t get lost.)
Can you perhaps post a workflow, or at least a screenshot of the Excel Reader configuration, so we can better understand what the trouble is?
Generally you want to use workflow relative paths for workflows that are going to be moved between a local Analytics Platform and a KNIME Server. If you haven’t already, you may want to check out the part of our documentation that describes how to implement relative paths:
https://docs.knime.com/2021-06/analytics_platform_file_handling_guide/index.html#relative-to
Hi Scott, appreciate the quick response.
The only snapshot I have would be the Excel Reader node with a red ‘X’, unfortunately. No errors were produced. I have been using Absolute path to the file with success in an older server (KNIME 4.3.2) but in this new one (KNIME 4.3.3) the same WF gets stuck at the Excel Reader. BUT, the workflow works if I point the datafile on the old server. Both paths work perfectly fine on my local Workspace copy.
The two paths are as follows:
WORKS in both OLD and NEW servers: knime://knime-server/Datasets/dataset.xlsx
WORKS only on my local Workspace: knime://knime-server-new/Datasets/dataset.xlsx
I tried your suggestion of going with a Relative path, and it works, but only on the Server, which is a bit inconvenience for local testing.
knime://knime.mountpoint/Datasets/dataset.xlsx
I guess I would have to replicate the Server’s Group structure for this to work?
Thanks!
Hi all
Having a very similar problem that I can’t get to the bottom of. For me it’s a problem of writing the output.
A new workflow on our server works fine if run via the temporary copy (yellow bar 
)The excel outputs are correctly written to Local File System using the following pattern:
\\knimeserver01\KNIMESharedFolder\filename.xlsx
This is a shared folder created on our knimeserver where we store our outputs (not being able to write to the network)
However, launching the workflow either with a rightclick in KNIME Explorer or via the webPortal results in the following workflow message
Excel Writer 0:218 - WARNING: Please specify a file
Hi @zedleb , when you are running the workflow as a temporary copy, you are running it from your local.
When you are running it otherwise, it’s running from the knime server.
\\knimeserver01\.... is a network drive, and you mentioned that the server is “not being able to write to the network”.
So, on the server, you need to point to the local location of the server, where ever it is in the server.
Hi @szhu ,
That should not be the case. That’s exactly the purpose of the Relative path in that it should not matter where you are. It’s relative to the workflow.
That would be an alternative, if you don’t want to change the path when testing. Tagging @zedleb also on this part where you are using an absolute local path. You probably need to set up your local structure the same as your server if you want to use the same path on server and locally for testing.
Hi @bruno29a
Thanks for the rapid reply!
The path the node is writing to is local to the knimeserver, next to the workflow_repository.
As I said we created this shared folder to store our outputs as we cannot write from Knime over the network to our file servers.
Other scheduled workflows on the server write quite happily to this KNIMEShare folder…I’m flummoxed!
No problem @zedleb
So, on the server, your path should be:
E:\KNIMEShare\filename.xlsx
You can’t use \\knimeserver01\KNIMESharedFolder\filename.xlsx on the server.
Generally that’s true, yes.
The other thing you could try is - assuming it’s not a huge file - to include the file within the workflow itself, in its /data folder. Then you can use the “Relative to current workflow data area” option and it should work the same whether on AP or on the server.
Hi
I’m so puzzled by this!
The KNIMEShare path I used works perfectly for all my other workflows running on the server.
Using the E:\KNIMEShare…version gives the same error.
I used to be able to select the KNIMEShare folder from recent items but now I have this
Doesn’t look right does it? 
Hi @zedleb , the new screenshot does not seem to be showing the same system as your previous screenshot.
In your previous screenshot, drive E: was labeled as “Database” while in this screenshot, it’s labeled as “KNIME”.
Also, why are you looking into Recent Items? Recent Items is just a shortcut to what you recently used. It’s a “nice to have”, meaning you do NOT HAVE to use it. If you can find what you need there, then good, if not, then go browse through your drives.
All,
My problem is solved. Hindsight is 20/20 but I should have known that ‘knime-server’ is a system-level setting on the server itself. Below are professional notes from support:
"
This is a problem of the default mountpoint. The remote executor doesn’t know the mountpoint knime-server-new. This mountpoint is known only by his local AP. There are two options:
com.knime.server.default_mount_id= [RT]
Specifies the name of the default mount ID. This is fetched, when clients set up their mount point to the server. Defaults to the server’s hostname.Env: KNIME_SERVER_DEFAULT_MOUNT_ID=
"
I see some of you may be having different issues but hope this helps some of you!
Hi @bruno29a
I used to have to use recent items precisely because I couldn’t browse through the drives!
However, this morning I saw for the first time the full network available…bingo…I thought.
But nope, I navigated, I selected the path, I deleted files and retried, I copied and pasted Writer nodes from functioning server workflows and just changed the filename…
Still the same error…and not the most helpful error message either 
I guess I could test using a relative path, but the fact that the exact same path works for other workflows running off the server make no sense to me.
Is there any chance that those workflows running off the exact same path were created by someone else? I am curious if this is a permissions issue where some users may not have access to write to the E: drive locations.
Can you post the current error you are receiving when trying to execute the workflow on the Server as I am not sure which one we are currently on in the thread.
Thanks,
Zack
Hi @ztrubow
No I’ve tested with nodes taken from workflows I have created (tried with csv writer also in case).
The error message is always the same
Please specify file
I’m getting nervous now that it’s a ridiculously simple error that I’ve made somewhere!
Is it possibly due to our upgrading our local versions of Knime…? The server is out of step with a workflow created in an more recent local version?
hi @zedleb,
This could possibly be an issue, if the workflow was created with a different version of KNIME AP than the executor version, you could see some unexpected issues with nodes. Please try to get both KNIME AP and Executor on the same version, recreate the workflow, and try running the workflow again to see if you still get the same error.
Thanks,
Zack
The error was definitely due to the Server and AP being out of step.
All working now.