Mounting Windows SMB Shares on Siemens IOT2000 for Node-RED

Overview

The SIMATIC IOT2000 family (IOT2020 and IOT2040) is a Siemens edge gateway intended to sit between the OT network and a higher-level MES or engineering host. The IOT2020 uses an Intel Quark SE x86 CPU with 1 GB of RAM; the IOT2040 uses the Quark x1020 with the same RAM and adds a second Ethernet port, RS232/RS485, and battery-backed RTC. Both ship with a Yocto-based Linux image (Siemens Example Image V2.6.x or V3.x) that includes Node-RED 0.20 or newer, but not the CIFS client tools. Out of the box the IOT2000 cannot attach a Windows SMB share, and the built-in Node-RED file in and file out nodes operate exclusively on local filesystem paths.

This article documents the production-grade procedure for letting a Node-RED flow read and write files that physically live on a Windows host: prepare the SMB share, install or build cifs-utils on the IOT2000, perform a one-shot mount, drive the share from a Node-RED flow, and finally make the mount persistent across reboots. Each step gives the exact command, the expected output, the error codes that appear when the step fails, and the field-tested fix. The article ends with a troubleshooting matrix, security analysis, and an alternative-architectures table that covers FTP, SFTP, HTTP, MQTT, and Git-based distribution.

Prerequisites and Components

Before touching the Linux side, validate the network path. From the IOT2000 shell:

If nc -zv reports Connection refused or Connection timed out, the issue is the Windows firewall or the SMB service, not Linux. Resolve the network layer first.

SMB / CIFS Protocol Background

Server Message Block (SMB) is the file-sharing protocol implemented by Windows. Common Internet File System (CIFS) is the historical dialect and the name Linux adopted for its client implementation. Modern mount.cifs negotiates SMB2 or SMB3 when the server advertises them. The relevant version is selected with the vers= mount option. The valid values are 1.0, 2.0, 2.1, 3.0, and 3.1.1. SMB1 was deprecated by Microsoft in 2014 and removed from cifs-utils in version 6.11. A 2024-era IOT2000 image should never negotiate SMB1.

Step 1: Configure the Windows SMB Share

1. Create a folder on the Windows host that will hold the recipes, for example D:\Recipes.
2. Right-click the folder, choose Properties → Sharing → Advanced Sharing, tick Share this folder, and set a share name such as Recipes. The resulting UNC path is \\HOSTNAME\Recipes or \\192.168.10.99\Recipes.
3. Click Permissions, add the Windows account that the IOT2000 will use, and grant at minimum Read. For write access from Node-RED, grant Change or Full Control.
4. Open Control Panel → Programs and Features → Turn Windows features on or off and confirm that SMB 1.0/CIFS File Sharing Support is disabled. Enable SMB Direct if your network adapter supports RDMA.
5. Open the Windows Defender Firewall with Advanced Security console and confirm that the inbound rule File and Printer Sharing (SMB-In) is enabled on the active profile (Domain, Private, or Public).
6. Test from a second Windows machine: \\192.168.10.99\Recipes should open, prompt for credentials, and list the folder contents.
7. From a Windows PowerShell prompt, validate the share with Get-SmbShare -Name Recipes. The output should report the share path, the description, and the scope.

Microsoft's official procedure for sharing a folder over a network is documented at File sharing over a network in Windows.

Step 2: Install cifs-utils on the IOT2000

The stock Siemens IOT2000 image does not ship cifs-utils. Two options exist.

Option A: Use a custom image that bundles cifs-utils

Some Siemens Application Examples deliver example images that bundle cifs-utils along with smbclient and several other utilities. If your project allows, use such an image; it is the lowest-risk path. Verify the package is present with:

Option B: Build cifs-utils from source on the device

When the production image is frozen, build the package in place. The build needs the development headers. On a Yocto-based IOT2000 image with the package feed enabled:

Download the cifs-utils release archive and transfer it to the IOT2000 (for example with WinSCP, scp, or the SD card). Connect to the device over SSH or via the serial console:

Expected output ends with lines such as libtool: install: /usr/bin/install -c mount.cifs /usr/sbin/mount.cifs. Verify the install with:

Without the setuid bit, the Node-RED exec node will fail with Operation not permitted even when the credentials file is in place.

Step 3: Mount the Share from the Linux Shell

Create the mount point and a credentials file so passwords do not appear in shell history, process listings, or the systemd journal.

cat > /etc/samba/iotcred <<'EOF'
username=iotuser
password=YourSecurePassword
domain=WORKGROUP
EOF
chmod 0600 /etc/samba/iotcred
chown root:root /etc/samba/iotcred

Perform a manual mount to validate the configuration end to end:

A successful mount returns to the prompt with no output. Verify the mount is in place:

The mount command should print a line similar to:

If the line is missing, the mount failed. Run dmesg | tail -20 to read the kernel log, which contains the underlying CIFS error message. The table in Step 5 covers the most common failure modes.

To unmount during testing:

If the share is a guest share (no password), replace the credentials file with the inline options guest,uid=1000,gid=1000 and remove sec=ntlmssp. If the share lives on a Windows host in an Active Directory domain, use sec=ntlmssp with domain=YOURDOMAIN in the credentials file, or migrate to sec=krb5 with a valid /etc/krb5.keytab for full Kerberos authentication.

Step 4: Build the Node-RED Flow

Once the share is mounted locally, Node-RED's built-in file in and file out nodes read and write the recipes without any custom node or extra palette.

4.1 Read a recipe on a trigger

1. Drag an inject node onto the canvas, set Payload to a timestamp string, and set Repeat to a 5-minute interval (interval with 300 seconds, or a cron expression).
2. Drag a file in node, set Filename to /mnt/recipes/current.csv, and leave Format as utf-8 string.
3. Drag a debug node.
4. Wire inject → file in → debug.
5. Click Deploy. Each inject tick produces a debug message containing the current recipe CSV.

4.2 Write a recipe from an HTTP upload

1. Add an http in node configured as POST /upload with File upload enabled.
2. Add a function node that sanitises the filename and moves the buffer to the payload:
3. Add a file out node, leave its Filename property empty so it reads from msg.filename, and set the action to overwrite file.
4. Add an http response node with status 200.
5. Wire http in → function → file out → http response.

4.3 Sample function node

// Build a safe filename
var name = (msg.payload && msg.payload.name) || "recipe.csv";
// Strip path components to avoid directory traversal
name = name.replace(/^.*[\\\/]/, "");
// Replace unsafe characters
name = name.replace(/[^A-Za-z0-9._-]/g, "_");
// Refuse empty or hidden names
if (!name || name.charAt(0) === ".") {
    node.warn("Rejected filename: " + name);
    msg.payload = "invalid filename";
    msg.statusCode = 400;
    return [null, msg];
}
msg.filename = "/mnt/recipes/" + name;
if (msg.payload && msg.payload.buffer) {
    msg.payload = msg.payload.buffer;
}
return msg;

4.4 Listing the share contents

The built-in file in node does not list directories. Use the exec node to call ls -1 /mnt/recipes and parse the result in a function node:

var lines = (msg.payload || "").split("\n");
var files = [];
for (var i = 0; i < lines.length; i++) {
    var n = lines[i].trim();
    if (n.length > 0) files.push(n);
}
msg.payload = files;
return msg;

Feed the resulting array to a dropdown UI node so the operator can pick a recipe from a list rendered by the Dashboard. For real-time updates, place the exec node inside a flow that fires when a file-system change occurs; on Linux this is best done with inotifywait in a polling loop, since cifs shares do not deliver native inotify events.

4.5 Detecting changes written by the Windows host

The cifs client uses the kernel's directory entry cache, which by default holds entries for 30 seconds. Add the cache=loose option to the mount if the operator changes recipes interactively on the Windows side and the IOT2000 must see the change within a few seconds. For sub-second freshness, run an exec node every second that does ls -1 /mnt/recipes and compares the output to the previous tick.

Step 5: Persist the Mount Across Reboots

A mount performed with mount -t cifs does not survive a reboot. The two field-proven approaches are fstab and a systemd unit with retry logic.

5.1 /etc/fstab entry

Add a single line to /etc/fstab:

The _netdev option tells systemd to wait for the network before attempting the mount. On systemd-equipped IOT2000 images (V3.x and newer), the x-systemd.automount option mounts the share on first access, which eliminates boot-time race conditions when the Windows host takes longer to come up than the IOT2000.

Test the fstab entry without rebooting:

The dry run reports what would be mounted; the actual mount happens on mount -a or on the next reboot.

5.2 Autostart script (rc.local / systemd unit)

For older images without full fstab support, or when the share is not always reachable, a small autostart script with retry logic is more robust. Create /opt/scripts/mount-recipes.sh:

#!/bin/sh
# mount-recipes.sh - retry mount of Windows share on boot
LOG=/var/log/mount-recipes.log
SHARE="//192.168.10.99/Recipes"
MNT="/mnt/recipes"
OPT="credentials=/etc/samba/iotcred,vers=3.0,sec=ntlmssp,uid=1000,gid=1000,soft,timeo=3000"

echo "=== mount-recipes start $(date) ===" >> "$LOG"
if mount | grep -q "${MNT} type cifs"; then
    echo "already mounted" >> "$LOG"
    exit 0
fi
for attempt in 1 2 3 4 5 6 7 8 9 10; do
    if mount -t cifs "$SHARE" "$MNT" -o "$OPT" >> "$LOG" 2>&1; then
        echo "mounted on attempt $attempt" >> "$LOG"
        exit 0
    fi
    echo "attempt $attempt failed, sleeping 10s" >> "$LOG"
    sleep 10
done
echo "FAILED after 10 attempts at $(date)" >> "$LOG"
exit 1

Make it executable and wire it into systemd:

cat > /etc/systemd/system/mount-recipes.service <<'EOF'
[Unit]
Description=Mount Windows Recipes share
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=300
StartLimitBurst=5

[Service]
Type=oneshot
ExecStart=/opt/scripts/mount-recipes.sh
RemainAfterExit=yes
Restart=on-failure
RestartSec=30

[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable mount-recipes.service
systemctl start mount-recipes.service

Verify the service is active and the share is mounted:

5.3 Re-issuing the mount from Node-RED

For a more dynamic pattern, drive the mount from a Node-RED exec node. The mount command requires root, so Node-RED must run as root, or the binary must be setuid. Running all of Node-RED as root is a poor security practice. The recommended approach is a small setuid wrapper that only accepts a known share and mount point.

cat > /usr/local/bin/mount-recipes <<'EOF'
#!/bin/sh
# mount-recipes - fixed share and mount point, setuid root
exec /usr/sbin/mount.cifs //192.168.10.99/Recipes /mnt/recipes \

  -o credentials=/etc/samba/iotcred,vers=3.0,uid=1000,gid=1000,soft,timeo=3000
EOF
chmod 4755 /usr/local/bin/mount-recipes
chown root:root /usr/local/bin/mount-recipes

The Node-RED exec node then invokes /usr/local/bin/mount-recipes with no arguments. If you need the password supplied dynamically, pass it on stdin rather than on the command line. The exec node can be configured to send the password string to the spawned process's stdin, where mount.cifs will read it during the password prompt phase.

Verification and Acceptance Test

1. Share reachability. From the IOT2000, run nc -zv 192.168.10.99 445 and confirm the port is open.
2. Mount present. Run mount | grep recipes. The output must include a cifs line with the expected options.
3. Read path. Deploy a file in node reading /mnt/recipes/current.csv and observe the debug payload. The payload must match the file on the Windows host.
4. Write path. Trigger a file out node writing a known string. From a second Windows machine, run Get-ChildItem \\192.168.10.99\Recipes in PowerShell. The file size and timestamp must update.
5. Persistence. Run reboot on the IOT2000. Wait 60 seconds, log in over SSH, and repeat steps 2–4 without manual mounting. The systemd unit or fstab must have remounted the share.
6. Error handling. Power off the Windows host (or block port 445 with a firewall rule). Within 30 seconds, the mount-recipes service should report retries in the journal. The Node-RED file in node should report an error in its status badge and the debug tab.
7. Recovery. Restore the Windows host. Within 30 seconds, the next retry or the next access to /mnt/recipes should re-establish the mount.

Performance Tuning

The cifs client exposes several tunables that affect throughput and freshness on a plant network.

For multi-megabyte recipe files, the bottleneck is almost always the kernel's copy-from-user path, not the wire. A 1 MB read on a 100 Mbit link completes in well under a second; a 50 MB file can take 5–10 seconds and block the Node-RED event loop. Use streaming writes via the exec node and dd for files larger than a few megabytes.

Troubleshooting Matrix

Security Considerations

Sharing files between a production control system and a Windows workstation is a deliberate act and must be evaluated against the IEC 62443 zone and conduit model. Treat the Windows host as a higher-trust zone, the IOT2000 as a cell-site controller, and the SMB session as a conduit that crosses the boundary.

• Credentials storage. The credentials file at /etc/samba/iotcred must be mode 0600, owned by root. Never embed credentials in Node-RED flow JSON files; export flows to an offline editor and check the JSON for accidental leakage before commit.
• Transport encryption. SMB3 with sec=ntlmssp signs but does not encrypt traffic. For sensitive data, require sec=ntlmssp over an isolated VLAN, or migrate the recipes to SFTP/HTTPS with mutual TLS.
• Protocol version. Pin vers=3.1.1 when the Windows host supports SMB3.1.1 encryption. Add seal or sign in the sec= option on cifs-utils ≥ 6.13 to enforce signing.
• Account scope. Create a dedicated Windows user iotuser with the narrowest possible share rights and an unguessable password. Disable interactive logon for the account in Active Directory Users and Computers.
• Network segmentation. Place the IOT2000 and the recipe host in the same engineering VLAN. Do not route SMB across the process control network.
• Audit. Enable Windows security auditing for logon and file access on the share. Forward events to the central SIEM. On the IOT2000, log all mount and umount invocations to /var/log/messages with auditd rules.
• File integrity. If the recipes drive safety-relevant control logic, compute a SHA-256 hash of the file on the Windows side and verify it on the IOT2000 in the Node-RED flow before consuming the data.

For a high-level primer on configuring SMB sharing on Windows, review Microsoft's File sharing over a network in Windows guide before exposing the share to the IOT2000.

Alternative Architectures

CIFS is convenient but not always the right tool. Consider the alternatives below when the recipe set grows, when the Windows host must be replaced by a version control system, or when the IOT2000 needs to be portable across plants.

The IOT2000 has enough CPU and RAM to run a small HTTP or MQTT client natively, so any of the alternatives can be implemented without the cifs-utils dependency. For pure local file access on the IOT2000 itself, leave the recipes on the SD card and let a service on the Windows host push changes through HTTP or SFTP.

Operational Notes

A few additional points observed in the field.

• The cifs module is built into the standard IOT2000 kernel, so modprobe cifs is rarely required. If lsmod | grep cifs returns nothing, the kernel on your image does not include cifs support and you must rebuild the kernel or switch to a custom image.
• The IOT2020 has 1 GB of RAM. A long-running cifs session that reads large files can fragment the page cache and starve Node-RED. Set vm.swappiness=10 in /etc/sysctl.d/ to favour dropping cache over swapping.
• DNS resolution on the IOT2000 is sometimes slow when the engineering VLAN does not advertise a DNS server. Use the IP address in the UNC path or add the Windows host to /etc/hosts to avoid mount hangs during boot.
• When the IOT2000 is in a DMZ and the Windows host is inside the OT network, an SMB session is typically allowed only inbound. The mount direction (IOT2000 → Windows) is supported by the IOT2000's default firewall, so no extra rule is needed.
• The mount survives a Windows reboot on the share host if soft and timeo=3000 are set. The next access after the Windows host returns re-establishes the session automatically.

FAQ