BadResourceUnavailable
BadServer limits
BadResourceUnavailable means the server needs something outside itself to answer you and cannot reach it: a database, a file, a device driver, a licence, a worker thread. Look at what the server depends on rather than at your request, which is usually correct.
What you actually see
Part of the address space works normally while one branch, one service or one device consistently fails, often starting at a time that matches a restart or a maintenance window elsewhere.
Why it happens
- A backend the server fronts is downHistorians, databases and aggregation sources are separate processes. When the server cannot reach them it reports the resource as unavailable rather than pretending the data does not exist, which is why current values keep working while history fails.
- A licence or feature key is missing or expiredCommercial servers gate connections, tag counts and optional service sets behind licences. An expired or unreachable licence server turns a working configuration into this code with no configuration change on anyone part.
- File or handle exhaustionFile transfer, certificate stores, log rotation and archive access all consume handles. A process at its file descriptor limit fails these operations while in-memory work continues, which makes the failure look selective.
- A thread pool or connection pool at its ceilingServers that dispatch work to a bounded pool refuse new work rather than queueing indefinitely. This appears under load and clears when load drops, so it looks intermittent and correlates with shift changes or reporting jobs.
- The underlying device or fieldbus link is unavailableOn gateways, a downstream device that is unreachable makes the resource behind a branch of the address space unavailable. Depending on the product you may see this, or a device-family code such as BadNoCommunication on the individual values.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Identify which resource the failing branch depends onMap the failing NodeIds to their source: a device, a database, a file store or an external service. The pattern of what still works is the strongest clue, so record precisely which operations succeed.
- Check the server host, not the clientOn the server host, check the dependent service is running and reachable, check free disk and file descriptors, and check the process log around the first failure timestamp. This is a server-side problem and the client cannot fix it.
- Verify licensing stateConfirm the licence is present, unexpired and reachable if it is served over the network. Licence checks are a common cause of an entire feature disappearing after a host reboot.
- Reduce concurrent demand while you diagnosePause reporting jobs and large history queries so the pool recovers. If the failures stop, the ceiling is concurrency and the fix is bounding client demand or raising the pool size deliberately.
- Make the client degrade rather than hammerTreat this code as retryable with bounded exponential backoff and jitter. Immediate retries make a resource shortage worse and can turn a brief outage into a sustained one.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| KEPServerEX | Driver-level and licensing problems commonly surface as an unavailable resource on the affected channel while other channels stay healthy. Check the event log on the server host first. |
| Ignition | A history query that fails while live tags are fine points at the historical provider and its database connection rather than at the OPC UA layer. |
| UA-.NETStandard (C#) | Node managers that front external systems return this when the external system is unreachable. The server log around the first occurrence normally names the dependency directly. |
| open62541 (C) | On embedded targets this frequently means a file handle or a fixed buffer pool rather than dynamic memory. Check the configured limits in the build as well as the runtime state. |
| OPC Publisher | A missing or non-persistent volume mount is a classic cause on containerised deployments: the certificate store or archive path is not where the server expects, and a non-persistent pki volume also regenerates the application certificate on every restart. |
| Prosys | When the same operation succeeds against a simulation server on the same network, the dependency is on the target server host and not in the request or the client. |
What it looks like in the log
HistoryRead failed: BadResourceUnavailable (historian connection refused)
License check failed; feature unavailable
Too many open files; unable to open certificate storeConfirm the fix
Restore the dependency, retry the exact operation that failed, and confirm it succeeds repeatedly under normal load rather than once immediately after a restart.
Stop it happening again
Monitor the server dependencies directly, alarm on licence expiry ahead of time, keep persistent volumes for certificate and archive paths, and give clients bounded backoff so a short outage does not amplify.
Stuck on more than one of these? The troubleshooting clinic works through broken configurations end to end, on camera.
Troubleshooting clinic →Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.