Trouble writing to SMB files/directories

General
1

I have a small QNAP server which I access from Windows 10.
I am running node red on my PC.

Although I can access my QNAP shares as normal drive letters, and create files, directories etc from all the usual utilities, whenever I use node-red to try to write or copy a file using the standard nodes or the node-red-contrib-filesystem nodes, I get an error of the following form:

ENOENT: no such file or directory

Does anyone have any ideas?

Thanks

B.

2

How are you running Node-RED on the Windows PC? Are you running it with the same user account as your standard login? And when does it start? Do you start it before any user login?

Also, within a flow, use an exec node to do a pwd command and a directory listing to see what results you get.

3

Hi, thanks for the reply.

I use a CMD window to issue the "node-red" command. So it's running in my user context.

a cd (not pwd!) command displays, for some reason, the windows/system32 directory, but that's really a factor.

The point is my username has write access to the Qnap smb shares via the drive letter: path, so why can't node-red see the same path?

B.

4

Looks like the problem is accessing mounted shares!

5

Success.

Apparently the solution is to specify the files in UNC format. Drive letter mappings don't work!

Can someone tell me if it is possible to use drive letter mappings by some other clever means?
E.g. @knolleary ?

Thanks!

B.

6

Wait one while I try - but I'm pretty certain they do work.

Correction - wait 10 while I fix my network shares that appear to have been broken by the upgrade from W10 to W11! :frowning:

7

I did a search for drive letter mappings and found this, which implies it is a general problem

shared folders in windows

and this

Node-red running on Windows accessing File on NAS

and no success other than using a UNC, so I guess that clears it up for me.

I suggest an addition to the document Running on Windows which includes the little wrinkles you might come across actually running flows on Windows, rather than just getting Node Red running on Windows.

@knolleary
The drive letter concept is (sadly considering Windows NT came from Vax/VMS) an inherent part of Windows. Using them for mapped drives clearly doesn't work, so I do think a worked example of using the UNC notation (preferably with forward slashes) ought to be included in that document.

Thanks!

B.

8

Sorry, I had a problem with a rogue file share yesterday and didn't get back to this. Tried today with this flow:

image
image955×110 7.73 KB

This is running on my Windows PC and the Z: share points to the root folder of my Debian Linux server.

It works perfectly as I stated I thought it would in my first post.

This variation also works perfectly:

image
image929×81 8.72 KB

In case you think that is unique to just the file-in node - here are some examples with an exec:

image
image947×75 9.84 KB

image
image948×101 9.27 KB

And they also work just fine.

So the / vs \ is not the issue.

This is incorrect as shown above.

It might have been at one time, but no longer.

Sorry to be pedantic but Windows/NT's origin lies with IBM and OS/2. In fact, I well remember those days and did a lot of work with OS/2 before moving on to Windows.

It does most certainly work. As does UNC access.

1 Like
9

#offtopic - ah happy days

3 Likes
10

Interesting.

I just ran a test on my old windows machine, and the problem does not occur there.

The only difference that I can see is that

Node Red V3.0.1 is installed on the new machine, but V3.0.0. on the old one.

Node.js is v16.16.0 on both

Where to go from here? As you can see, other people have had this problem, with apparently no resolution.
:thinking:

B.

-------------- PS ------------------
Off topic.

If you are going to be pedantic, you need all the facts! :upside_down_face:

MS and IBM split before work started on NT. MS hired Dave Cutler from Digital Equip. who was a Vax/VMS author. He didn't like OS/2 and modelled the underlying op sys on Mica, the next stage of VMS. Although I'm normally sceptical of Wikipedia, I was familiar with the issues at the time and find their accounts here and here and here to be quite good.

(My off the cuff remark was that 45 years ago I was working with VMS which had dynamic logical names with which you could point at a disk or subtree - as many as you want - and here we are in the 21st century still using 20+ letters of the alphabet...)

11

I'm using Windows 11 as it happens but the same still works for W10. I'm also using the latest beta but I tested on a clean install of Node-RED v3.0.2 as well. I'm using Node.js v16.14.0

I also just tested with my Synology NAS just in case something was different but that works as well.

So we are back to trying to understand what is different between running something in Node-RED and running from the command line.

So two things. Can you please create a dummy file in the root of one of your shared drives and try to read it from Node-RED using a simple flow: trigger->file-read->debug. Then can you share the flow here so I can try it on my system?

Secondly, are you using DOS or PowerShell for the command line and if PowerShell, which version?

I did in fact check the facts before posting :grin: I did see a reference to Dave Cutler but the bulk of the OS was indeed developed initially with IBM. Shades of LAN Manager included as well of course. So doubtless the actual truth is a mix of all of these things.

12

Ok, here is the flow:

[
    {
        "id": "b7788b76618998c9",
        "type": "inject",
        "z": "abf5ea63e2bde491",
        "name": "",
        "props": [
            {
                "p": "payload"
            },
            {
                "p": "topic",
                "vt": "str"
            }
        ],
        "repeat": "",
        "crontab": "",
        "once": false,
        "onceDelay": 0.1,
        "topic": "",
        "payload": "",
        "payloadType": "str",
        "x": 150,
        "y": 220,
        "wires": [
            [
                "cc8509fa75f8b090"
            ]
        ]
    },
    {
        "id": "1305f97d9387aa79",
        "type": "debug",
        "z": "abf5ea63e2bde491",
        "name": "debug 19",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "false",
        "statusVal": "",
        "statusType": "auto",
        "x": 540,
        "y": 220,
        "wires": []
    },
    {
        "id": "cc8509fa75f8b090",
        "type": "file in",
        "z": "abf5ea63e2bde491",
        "name": "",
        "filename": "z:\\test.txt",
        "filenameType": "str",
        "format": "utf8",
        "chunk": false,
        "sendError": false,
        "encoding": "none",
        "allProps": false,
        "x": 340,
        "y": 220,
        "wires": [
            [
                "1305f97d9387aa79"
            ]
        ]
    }
]

Looks like this

image

Output on the failing computer:

18/03/2023, 15:29:34[node: cc8509fa75f8b090](http://localhost:1880/#)
msg : error

"Error: ENOENT: no such file or directory, open

Output on the succeeding computer:

18/03/2023, 15:31:09[node: debug 19](http://pavilion.local:1880/#)
msg.payload : string[32]

"This is not a test! It's a pipe!"

On both nodes, after a boot, I create an unprivileged CMD window and issue the command node-red

When you said this:

So we are back to trying to understand what is different between running something in Node-RED and running from the command line.

I'm not clear what you mean. I'm doing what seems to me to be identical operations on both computers. The older computer is running an earlier point version of Windows 10, but you are running Windows 11, so it can't be that.

Anyway, thanks very much for taking to the time to help me!

B.

13

Had to change the drive letter but:

image
image963×194 10.6 KB

Try this flow please:

[{"id":"9fa234d59f68ae6b","type":"inject","z":"d9f4668b3c173eb8","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"str","x":870,"y":160,"wires":[["7a72e7e623b9ece2"]]},{"id":"d2744dce77db82b0","type":"debug","z":"d9f4668b3c173eb8","name":"debug 109","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1300,"y":160,"wires":[]},{"id":"7a72e7e623b9ece2","type":"exec","z":"d9f4668b3c173eb8","command":"dir z:\\","addpay":"","append":"","useSpawn":"false","timer":"","winHide":false,"oldrc":false,"name":"","x":1070,"y":160,"wires":[["d2744dce77db82b0"],["d2744dce77db82b0"],["d2744dce77db82b0"]]}]

image
image777×79 6.61 KB

Could you then please do a net use command both from the cmd line and from the Node-RED exec node?

And that is, where I suspect the problem lies. seems might not actually be the same. But I can't quite work out why. Something about how node-red is running on the failing computer seems to be hiding

14

Oh, and you should update the failing machine to node-red v3.0.2 as well.

15

Did you check if node-red runs for whatever reason elevated? Because that might under windows also lead to not seeing a file share that is created by a user.

2 Likes
16

Before I start those tests, FYI I tried the flow on 2 other systems: One was a docker system on the same failing machine using WSL and that failed with the same problem

The other system was a windows laptop running an old version of node red 1.1.3 and that worked.

17

Thanks for the suggestion...

{hangs head in shame}

I did, indeed start it off in a privileged window. What a complete and utter fool!

Thanks so much for cracking the problem.

Thanks also to @TotallyInformation too!

Just off to the foot of my stairs....

B.

1 Like
18

Well spotted @cameo69 - annoyed with myself that I didn't think of that!

19

Don‘t be, I am just reading and sometimes it is easy to spot things from a distance. And you guys here in the forum are helping a lot of people.

1 Like
20

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.