Container Station 3.1.2.1742 bug

A frequently occurring error appears in my logs with a stack trace which follows. Claude.ai thinks it’s a bug in the go script. It crashes on any interface with no IPv4 address - in my case eth2 and eth3 (disconnected physical NICs). Model name: TS-673 and Firmware version: 5.1.9.2954 build 20241120.

Stack trace:

Wed, 03 Jun 2026 13:48:59 EDT   INFO    analytics/analytics.go:22       started analytics worker
Wed, 03 Jun 2026 13:48:59 EDT   INFO    images/update_images.go:57      started update image checker
Wed, 03 Jun 2026 13:49:21 EDT   ERROR   container-station/main.go:120   worker panic: runtime error: index out of range \[0\] with length 0
Wed, 03 Jun 2026 13:49:21 EDT   ERROR   container-station/main.go:121   worker panic: goroutine 63 \[running\]:
runtime/debug.Stack()
/usr/local/go/src/runtime/debug/stack.go:26 +0x5e
main.PreSetup.func2({0x77afc0?, 0xc000b852d0?})
/src/cmd/container-station/main.go:121 +0x8a

/go/pkg/mod/sauron.qnap.com/core-tech/cs-team/lib/qlib@v0.2.66/pkg/routine/routine.go:52 +0x83
panic({0x4b2460?, 0xc00045f428?})
/usr/local/go/src/runtime/panic.go:792 +0x132

/src/internal/worker/network-cache/networkconflict.go:129 +0xa94 sauron.qnapcom/core-tech/cs-team/container-station/container-station-api-server/internal/worker/network-cache.(\*NetworkConflictMonitor).Run.func2({0x0?, 0x12251f3?})
/src/internal/worker/network-cache/networkconflict.go:87 +0x1c
reflect.Value.call({0x307000?, 0xc0005156c0?, 0xc0002abbe0?}, {0x563308, 0x4}, {0xc000051648, 0x1, 0x1?})
/usr/local/go/src/reflect/value.go:584 +0xca6
reflect.Value.Call({0x307000?, 0xc0005156c0?, 0x0?}, {0xc000051648?, 0xc0000515e0?, 0x12c4650?})
/usr/local/go/src/reflect/value.go:368 +0xb9
sauron.qnapcom/core-tech/cs-team/lib/qlib/worker.(\*worker).exec(0xc0001ade00, {0x788b50, 0xc0005129b0}, {0x307000?, 0xc0005156c0?}, 0x0, 0x0)
/go/pkg/mod/sauron.qnap.com/core-tech/cs-team/lib/qlib@v0.2.66/worker/worker.go:197 +0x245
sauron.qnapcom/core-tech/cs-team/lib/qlib/worker.(\*worker).run(0xc0001ade00, {0xc0001f6620, 0x2, 0x2})
/go/pkg/mod/sauron.qnap.com/core-tech/cs-team/lib/qlib@v0.2.66/worker/worker.go:238 +0x297

/go/pkg/mod/sauron.qnap.com/core-tech/cs-team/lib/qlib@v0.2.66/worker/worker.go:163 +0x7b3
sauron.qnapcom/core-tech/cs-team/container-station/container-station-api-server/internal/worker/network-cache.(\*NetworkConflictMonitor).Run(0xc0002c8b40, {0x788b50, 0xc000512960})
/src/internal/worker/network-cache/networkconflict.go:96 +0x1d5
reflect.Value.call({0x2effc0?, 0xc0005155f0?, 0x13?}, {0x563308, 0x4}, {0xc0002c8b58, 0x1, 0x1?})
/usr/local/go/src/reflect/value.go:584 +0xca6
reflect.Value.Call({0x2effc0?, 0xc0005155f0?, 0x0?}, {0xc0002c8b58?, 0x0?, 0x0?})
/usr/local/go/src/reflect/value.go:368 +0xb9

/go/pkg/mod/sauron.qnap.com/core-tech/cs-team/lib/qlib@v0.2.66/pkg/routine/routine.go:62 +0x5c
created by sauron.qnapcom/core-tech/cs-team/lib/qlib/pkg/routine.execGo in goroutine 58
/go/pkg/mod/sauron.qnap.com/core-tech/cs-team/lib/qlib@v0.2.66/pkg/routine/routine.go:48 +0x2dd

Hmm. Is this path name showing QNAP’s desire to rule everyone? Is this where that cursed Maia ended up after being dispatched from Mordor?

:nerd:

Greek to me. This was the analysis from Claude:

  1. Product: Container Station 3.1.2.1742
  2. Bug: NetworkConflictMonitor.checkNetwork() panics with index out of range [0] with length 0 when any network interface has no IPv4 address assigned (disconnected NICs, dummy interfaces, etc.)
  3. File/line: networkconflict.go:129
  4. Fix needed: Add if len(addresses) == 0 { continue } bounds check before indexing
  5. Impact: Service crashes and restarts every ~60 seconds, flooding QTS notification log

Or at-least, to keep an eye on everyone. :wink:

I mean 5.2.9 is the current firmware, I would at least update the 18 month old firmware version to begin with.
After that, a look at the Container YAML code could also help

I thought the firmware had been completely updated, however on checking it I had another couple of patches to apply. I applied those updates including required software updates and the issue persists. Currently at 5.2.9.3499 firmware. ContainerStation at 3.1.2.1742. Hopefully all the go fetch a rock activities completed now.

If it wasn’t requested here, it would be requested when you report this issue to QNAP via a support ticket.

That’s the right way to report bugs. :wink:

Funny you should mention that. Their ticket system would not let me submit one either online or from the help center app, and when trying to connect to a real human on the chat no one picked up.

When you attempted to create a ticket on the QNAP support site, what happened please?

It was just a message saying the ticket couldn’t be sent, try again. I tried a few times. I had attached a text file containing the details that the helpdesk app created as well as a small zip containing logs also created by the helpdesk app.

Try creating a ticket again, but don’t attach any files until support ask for them. Or until you’ve successfully created the ticket. :slight_smile:

That worked without the attachments. Thanks!

Resolution of this issue involved reinstallation of ContainerStation.