Web admin shows requested content not available on a full controller

Symptoms and what each points to

Match your controller against this list before changing anything.

• Every submenu answers "Requested content is not available" while a basic page, such as the firmware display, still loads. The web server is answering, so the service itself is running; the documented cause sat one level down, on the disk.
• Applications keep running. The runtime was executing normally while the pages failed, so storage is the suspect. Confirm it anyway with the CODESYS runtime running-or-stopped check before you touch the filesystem.
• The fault appeared after weeks of normal use. Retained install packages accumulate one runtime deployment at a time, so a flash that filled gradually matches this timing.
• A network change exposed it. The fault surfaced in the documented case when a NIC IP address needed changing, a job many controllers reach only through the web admin.

A dark panel screen on the controller itself is a different trail; start from the embedded controller video display checks.

Confirm the full filesystem with df

All of this runs over SSH from a laptop, the same access you use to provision an embedded module with no display attached.

1. Open an SSH session to the controller. The shell answers even when the web admin does not.
2. Run df and find the row whose mount point is /. Skip the rows for /boot, /home and the temporary filesystems; the root row is the one that matters.
3. Read the Use% and Available columns on that row. The fault reads 100% used and 0 available. The runtime vendor's diagnosis for the exact web admin message was shorter still: no free space left.
4. Run df again after each cleanup step to confirm the space returned.

The same SSH session also reaches cbm, the controller's console-based management tool, for the jobs the web pages normally handle.

Example: a 240 MiB root filesystem at 96 percent after cleanup

The inputs, each with its source:

Every value comes from the controller's df output after the Reset Origin cleanup. Before the fix, the same row read 100% used with no space available.

The rule in words: df computes Use% as used blocks divided by usable blocks, and usable blocks are used plus available. The 1K-blocks total is larger than that sum because the filesystem reserves a slice of its blocks for the root account, and df leaves that slice out of the percentage.

The arithmetic:

• Usable blocks: 222880 + 9692 = 232572.
• Use%: 222880 ÷ 232572 = 0.9583, so 95.8%, which df rounds to the 96 it prints.
• Free space: 9692 blocks × 1024 bytes per block = 9,924,608 bytes, about 9.5 MiB.
• Headroom: 100 - 96 = 4 percentage points above full.

Result: the reset left about 9.5 MiB free on a flash that had been completely full, and the web admin pages loaded again at that level.

Decision: a root row at 100% used with 0 available is the fault, and freeing root space is the fix; once the row reads below 100% and the pages load, the job is done. Reset Origin reached exactly this 96% row. Deleting the retained packages frees more, and the expected level for that route is given with the fix below.

Delete the retained install packages

The update tool deploys the runtime as Debian packages and leaves those install files on the controller after they are installed; that was the vendor's own diagnosis of the bug. Each deployment on an affected runtime leaves another set, and the sets add up on a small flash.

1. List the retained files: find /root -name 'codesys*.deb' -ls. Each hit should be a runtime install package, a name that starts with codesys and ends in .deb.
2. Delete the files the listing shows, giving the full path for each one.
3. Run df again. The documented procedure lands at about 89-90% used on the flash.
4. Open the web admin and load the submenu that failed. Pages loading is the confirmation.

The controller in this case ran runtime version 3.5.14.30 when its flash filled. The cleanup is a stopgap: the vendor marked the bug solved with the 3.5 SP15 runtime, so the packages return with the next deployment until you upgrade.

Fallback: Reset Origin Device

If the listing comes back empty and the root row still reads 100%, use the reset. Right-click the controller entry in the device tree, the same tree you work in when you fix a runtime device mismatch safely, and choose Reset Origin Device.

Reset Origin Device deletes every file the CODESYS tools downloaded to the controller, which includes what the deployment put there. Keep your project archive and the runtime installer in hand and plan to redeploy after the reset. In the documented case the reset took the root row from completely full to the level in the example above, and the web admin came back.

After the reset, run df and confirm the row reads below 100%, then load the submenu that failed.

Keep it from coming back

• Upgrade the runtime to 3.5 SP15 or later. The retained-package bug is reported solved from that release on.
• Run df after every runtime deployment. On affected versions, each deployment leaves a new set of install packages, so usage climbs toward 100% one update at a time. A root row creeping past 90% is the early warning.
• Budget the flash. The whole root filesystem in this case was about 240 MiB, so moving to a fixed runtime protects more space than any cleanup.

Recommendation: If the root row reads 100% used with 0 available, list and delete the retained codesys .deb packages first and confirm the row drops below 100%; run Reset Origin Device when the row still reads 100% after that, accept the redeploy it requires, and take the runtime upgrade that stops the packages coming back.

Questions