When a network storage problem made the whole server look frozen

Why this kind of sharing is useful

NFS is one way for a computer to use a folder stored on another computer almost as though it were local. It lets a main server run the applications while a NAS manages the larger collection of files. Separating those responsibilities makes storage administration simpler and allows several services to share the same data without copying it into each service.

Local disks avoid the extra network hop and are a sensible choice when one machine is enough. Network storage is useful when its shared access, capacity or separate management outweigh the additional connection that can fail. The same dependency that makes sharing convenient is what explains why several apparently independent applications can stall together.

This note is about the order of diagnosis, not a universal recovery command. An application waiting on files may appear frozen for a reason entirely outside its own code, so the safest next step is to establish whether the shared storage is reachable before restarting every affected program.

The setup in plain language

The main server runs several isolated services. Most of their media and shared data live on a separate Synology NAS. The server reaches those folders using NFS, a common method for providing storage over a network.

This arrangement keeps large amounts of data on the device designed to store it while the server focuses on running applications. It also creates an important dependency: services that need the shared folders cannot work normally when the NAS or the network connection to it stops answering.

That dependency is reasonable, but it needs to be understood before failure. During an outage, the server does not present a helpful banner saying that several problems are all waiting on the same storage. It allows each program to express the situation in its own irritating dialect.

What the outage looked like

The management interface became slow or unresponsive. Commands related to affected services could take a long time. Some applications stopped responding normally. Attempts to stop or restart storage-dependent workloads could hang while they waited on the same unavailable folder.

The entire server could appear frozen even though the processor, memory and local operating system were not necessarily the original problem. The missing storage path created a queue of waiting work, and that queue spread the symptoms far beyond the NAS.

This is why the outage was easy to misread. The visible problem was whichever service I happened to check first. The actual problem sat underneath several of them.

When several unrelated services stall together, look for the shared thing they are all waiting for.

Why storage waits can affect management

Programs do not always fail immediately when network storage disappears. Some requests wait because the storage may return. That behaviour can protect work during a brief interruption, but it can also make a longer outage feel as though the whole server has stopped.

A management command may need to inspect a service's files before completing. A shutdown may wait for a program to finish using storage. A status check may touch a folder that is no longer answering. Each action looks like a separate frozen command, but the waiting point is the same.

The result is a system that remains partly alive and increasingly difficult to manage. This is more confusing than a clean failure because enough still works to encourage random intervention.

Why restarting everything is risky

Restarting things feels productive. It is the home administrator's ceremonial first offering, and sometimes the equipment accepts it.

During a storage outage, however, restarting every affected service changes more state while the missing storage is still missing. A service may fail to stop cleanly, fail to start because its files are unavailable or enter a new state that obscures the original problem.

A full server reboot carries the same risk. If the NAS path remains unhealthy, the server returns and immediately asks several services to start against the same unavailable storage. The original outage now includes a complicated startup.

A reboot may eventually be appropriate, but it should not substitute for checking whether the shared dependency has recovered.

The recovery order that worked

I recover from the bottom upward. First, confirm that the NAS itself is responsive. Next, confirm that the network path between the server and NAS is stable. Then check whether the server's connection to the shared folder is healthy.

Only after ordinary storage access works again do I restart management services or application workloads that were blocked. This order removes the cause before treating the consequences.

It also limits unnecessary changes. If restoring the network path makes the waiting services recover, they may not need to be restarted at all.

• Confirm the storage appliance is responding normally.
• Confirm the physical and network connection is stable.
• Identify which services are waiting on shared storage.
• Restore the server's connection to the shared folders.
• Test an ordinary read and write through the same path.
• Restart only the services that remain unhealthy.
• Verify playback and routine management after recovery.

What changed permanently

Moving the storage connection to a newer NFS version improved behaviour in this setup. It provided a better working baseline and reduced some of the problems seen with the older arrangement.

The change was useful, but it did not cure physics. A newer NFS version cannot make an unreliable network adapter reliable or an unavailable NAS answer requests. It improves how the server and storage communicate; it does not remove the dependency.

Technical forums occasionally describe version changes as if selecting a newer number causes unreliable hardware to reconsider its life choices. Mine remained unmoved.

The network problem underneath the storage problem

The most serious outages were connected to instability in the faster NAS network path. When that link failed, NFS was one of the first places the consequences became visible because so many services depended on it.

Returning the NAS to a slower, stable connection reduced the speed available for large transfers but restored predictable storage access. That change mattered more than adjusting individual services because it addressed the common path.

This is a useful distinction: NFS exposed the failure, but the underlying network reliability was the larger issue. Blaming the storage method alone would have treated the messenger with considerable enthusiasm.

How I verified recovery

A successful mount command or healthy storage indicator was not enough. I tested the path in the way applications actually use it: ordinary directory access, file reads and writes, media playback and management operations that had previously stalled.

I also watched for delayed failures. A connection can appear healthy immediately after recovery and still become unreliable under normal use. The observation period needed to cover the same conditions and time frame in which the previous fault appeared.

Finally, I confirmed that routine management worked again. Storage is not fully recovered for this environment if the files are visible but every action involving a storage-dependent service remains painfully slow.

Reducing the blast radius

Not every service needs shared storage for every part of its operation. Keeping the server's operating system and basic management functions on local storage helps preserve some control when the NAS is unavailable.

It is also worth documenting which services require the NAS and which recovery tools remain usable without it. A short dependency map is more valuable during an outage than a long list of commands collected afterward.

Monitoring should cover the NAS, the network path and a real storage operation. A device responding to a simple network check does not guarantee that a shared folder can be read normally.

What I would do during the next outage

I would begin by naming the shared symptom: several storage-dependent services are waiting. That framing immediately reduces the temptation to troubleshoot five applications independently.

Then I would verify the NAS, network and shared folder in that order. I would avoid restarting unrelated services until the storage path had returned, and I would record the exact point at which normal access resumed.

The goal is not merely to recover faster. It is to make fewer changes while evidence is still available. Every unnecessary restart edits the scene of the crime.