I got help from Claude and changed the standard mounting from nfs 4 to nfs 3 for the webinterface.
Here is what Claude suggested:
My NFS server (Windows Server 2025) only accepts NFSv3, and the camera's built-in mount logic (both LCD and web interface) is hardcoded to attempt NFSv4, which fails for me.
This gets you:
- A working NFSv3 mount, reachable from both the camera GUI's storage picker and SSH
- The mount automatically re-established on every reboot, no manual SSH step required
- No recompiling of chronos-cam-app required
Camera: Chronos 1.4, firmware 0.7.2
NFS Server: Windows Server 2025
All commands below are run as root over SSH.
1. Patch the NFS mount command to force vers=3
Why: mountNetDrive.sh (the script that actually performs the mount — used by both the web interface's "Network Storage" form and by any manual call to the netShare CGI endpoint) hardcodes mount -t "nfs4". That's the root cause of the mount failing outright against servers that don't support/allow NFSv4.
What it does: From now on, any mount triggered through this script (web UI or CGI) uses vers=3 instead of the broken default.
Code:
# locate the script (should be here on 0.7.x firmware)
find / -iname "mountNetDrive.sh" 2>/dev/null
# -> /var/camera/scripts/mountNetDrive.sh
# back it up first
cp /var/camera/scripts/mountNetDrive.sh /var/camera/scripts/mountNetDrive.sh.bak
# change the nfs4 mount to nfs vers=3
sed -i 's/mount -t "nfs4" \${params\[2\]}:\${params\[3\]} \/media\/nfs/mount -t "nfs" -o vers=3 \${params[2]}:\${params[3]} \/media\/nfs/' /var/camera/scripts/mountNetDrive.sh
# verify only that one line changed
diff /var/camera/scripts/mountNetDrive.sh.bak /var/camera/scripts/mountNetDrive.sh
2. Restart the service so the patched script is actually used
Why: mountNetDrive.sh doesn't run standalone — it's the long-running process behind the netDriveHelper.service systemd unit (ExecStart=/var/camera/scripts/mountNetDrive.sh). It watches /tmp/mountRequest.nf via inotifywait for the rest of its life; editing the file on disk doesn't affect the already-running instance.
Code:
systemctl restart netDriveHelper
systemctl status netDriveHelper # should show active (running), new PID, inotifywait child process
3. Trigger the mount (this is what the web UI does internally)
Why: The netShare CGI script (called by the web interface's storage form) just writes the mount request into /tmp/mountRequest.nf; mountNetDrive.sh picks it up via its file watch and performs the actual mount. You can call it directly to mount without using the web UI at all — and it's what our boot automation (step 4) uses too.
Note: curl is not installed on the camera; use wget instead.
Code:
wget -qO- "http://127.0.0.1/cgi-bin/netShare?nfs=<your-server-ip>&mount=/<your-share-name>"
Expected response: {"Status": "succeeded"}. Confirm:
Code:
mount | grep nfs
# should show vers=3 in the options
At this point the share should also show up as a storage target in the camera's GUI under Util -> Storage.
It can be used by REST API with the tag nfs from now on.
4. Make it survive a reboot
Why: The mount itself is, of course, not persistent — nothing remounts it automatically after a reboot unless you set that up. There's also a timing dependency: the mount can only succeed once the network interface actually has an IP and once netDriveHelper.service (and thus mountNetDrive.sh's file watch) is up and running.
Rather than editing any vendor-owned files for this part, create a separate systemd unit (this survives future chronos-http package updates, since those only touch /lib/systemd/system/, not /etc/systemd/system/):
Notes on the specific settings:
- After=NetworkManager-wait-online.service ensures we don't even try before the network is actually up (on this camera, eth0 is managed by NetworkManager, and this wait-online unit exists and works for that purpose).
- ExecStartPre=/bin/sleep 30 and the retry loop (10 tries, 2s apart) exist because of the issue in step 5 below — without this margin, the mount attempt can race against (and get undone by) the camera's own LCD-interface logic
Code:
cat > /etc/systemd/system/chronos-nfs-automount.service << 'EOF'
[Unit]
Description=Auto-mount NFS share for Chronos camera after boot
After=netDriveHelper.service NetworkManager-wait-online.service
Wants=NetworkManager-wait-online.service
Requires=netDriveHelper.service
[Service]
Type=oneshot
ExecStartPre=/bin/sleep 30
ExecStart=/bin/bash -c 'for i in $(seq 1 10); do result=$(/usr/bin/wget -qO- "http://127.0.0.1/cgi-bin/netShare?nfs=<your-server-ip>&mount=/<your-share-name>"); echo "Attempt $i: $result"; if [[ "$result" == *succeeded* ]]; then exit 0; fi; sleep 2; done; echo "All attempts failed"; exit 1'
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable chronos-nfs-automount.service
5. Disabeling nfs v4 automount triggered by chronos-cam-app
Why this step exists: Even with steps 1–4 in place, the mount would disappear again a few seconds after boot. The chronos-cam-app has its own, separate, hardcoded NFS mount attempt that runs
once, ~15 seconds after camera the UI starts (checkForNfsStorage() in cammainwindow.cpp, wired up via QTimer::singleShot(15000, ...)). If it finds a stored NFS address/mount point in its settings, it force-unmounts /media/nfs and tries to mount it itself — with no version flag at all, defaulting to whatever the system negotiates (which fails against a server that requires v3), and it pops up a blocking "Mount failed" / "not reachable" dialog on the physical touchscreen.
It gets triggered because mountNetDrive.sh writes the mount details to /var/camera/webNfsMount.txt after every successful mount, and a separate 5-second timer in the chronos-cam-app (checkForWebMount()) reads that file and stores the values permanently in the app's settings (/var/camera/Settings/KronTech/camApp.conf) — which is exactly the trigger condition for the problematic 15-second boot check.
Two-part fix:
a) Stop it from happening again — prevent mountNetDrive.sh from writing that file (we don't need it; the LCD app doesn't need to know about a web-triggered mount for it to keep working):
Code:
grep -n "webNfsMount" /var/camera/scripts/mountNetDrive.sh
# note the line number of: echo "${params[2]} ${params[3]}" > /var/camera/webNfsMount.txt
# (line 114 on my 0.7.2 firmware — check yours before running this!)
sed -i '114s/^/#/' /var/camera/scripts/mountNetDrive.sh
sed -n '110,118p' /var/camera/scripts/mountNetDrive.sh # confirm only that one line got commented out
systemctl restart netDriveHelper
b) Clean up the setting that's already stored from previous mount attempts (otherwise the 15-second check still fires once more on the next boot using stale data):
Code:
cat /var/camera/Settings/KronTech/camApp.conf | grep -i nfs
# shows e.g. nfsAddress=192.168.100.6 / nfsMount=/CAMshare
echo "" > /var/camera/webNfsMount.txt
sleep 6 # give the LCD app's 5s poll timer a chance to pick up the empty file and clear its settings
cat /var/camera/Settings/KronTech/camApp.conf | grep -i nfs
# should now show empty values
5. Verify
After reboot:
Code:
mount | grep nfs
# should show vers=3
cat /var/camera/webNfsMount.txt
# should be empty
cat /var/camera/Settings/KronTech/camApp.conf | grep -i nfs
# should be empty
journalctl -b -u chronos-nfs-automount.service --no-pager
Also check the physical screen — no "Mount failed"/"not reachable" popup should appear anymore.
- A future chronos-http package update will likely overwrite /var/camera/scripts/mountNetDrive.sh with the original (unpatched) version, since it's owned by that Debian package. The chronos-nfs-automount.service unit itself (under /etc/systemd/system/) won't be touched, but the NFSv3 fix and the webNfsMount.txt suppression would need to be reapplied. A backup of the patched script is at /var/camera/scripts/mountNetDrive.sh.bak in case you want to diff against a future update.
- This only addresses the web/CGI mount path. The LCD interface's own "Utils → Network → NFS Network Storage" screen still can't mount NFSv3 on its own (that would require patching/recompiling chronos-cam-app itself, which is a much bigger undertaking per the earlier discussion in this thread).
Thanks for all the help so far. resolving the write protection on the files will enable me to get rid of the old unsecure smb1 storage solution.
