Prozesse, die auf gemeinsam benutzten Dateien arbeiten, synchronisieren den Zugriff auf solche Dateien über Sperren. Sperren auf Dateien oder Dateibereiche (Records) werden mit dem Systemaufruf fcntl() gesetzt, freigegeben oder abgefragt. Das NFS-Protokoll unterstützt das Setzen von Sperren nicht, weil das NFS-Protokoll "zustandslos" angelegt ist: Wenn der NFS-Client beim Server eine Aktion auslöst, erzeugt diese Aktion beim Server keinen Zustand, der mit dem Absturz des Servers verloren wäre. Es wird also entweder
überhaupt kein Zustand auf dem Server erzeugt (z. B. beim Lesen von Daten) oder
ein "permanenter" Zustand auf dem Server erzeugt (z. B. beim Erzeugen oder Löschen von Dateien). Permanente Zustände bestehen nach einem Absturz des Servers weiter.
Aus der Sicht eines NFS-Clients ist ein Server, der nach einem Absturz wieder anläuft, nur ein sehr langsam arbeitender Server. Analog ist ein nach Absturz wieder anlaufender Client für den NFS-Server lediglich einer, von dem längere Zeit keine Aufträge gekommen sind. Dieses komfortable Wiederanlaufverhalten macht NFS sehr robust und ist der Zustandslosigkeit des NFS-Protokolls zu verdanken.
Das Setzen von Sperren ist mit einem zustandslosen Protokoll aber nicht möglich. Sperren müssen beim NFS-Server registriert werden und sind dort nach einem Server-Absturz verloren (es sei denn, man legt jede Sperre in einem nicht-flüchtigen Speicher ab). Das Arbeiten mit Sperren auf einem NFS wird daher in einem gesonderten Protokoll "NLM" (Network Lock Manager) realisiert. Vom Network Lock Manager werden nur sogenannte "advisory" Sperren unterstützt. D.h. die Sperren wirken nur, wenn alle Benutzerprogramme für die Zugriffe auf die entsprechenden Dateien bzw. Dateiabschnitte mit Sperren arbeiten. Das Programm lockdsrv implementiert das NLM-Protokoll auf der Server-Seite. Beim Client ist NLM im Systemkern implementiert. Der Client ist darüber hinaus aber noch auf Hilfsdienste angewiesen, die ihm der auf dem Client laufende Prozess lockdclnt zur Verfügung stellt.
Beim Arbeiten mit Sperren über NFS muss unbedingt beachtet werden, dass die Client-Prozesse jeden Zugriff auf eine gemeinsam benutzte Datei puffern. Das Setzen von NFS-Sperren sorgt dafür, dass der NFS-Client die Pufferung von Lese- und Schreibdaten unterlässt. Wenn aber sowohl ungepufferte als auch gepufferte Zugriffe benutzt werden (d. h. solche, vor denen keine Sperre gesetzt wurde), kann die Konsistenz der gemeinsam benutzten Dateien nicht mehr garantiert werden. Ausnahme: Alle Client-Prozesse arbeiten auf demselben Client-Rechner (d. h. sie benutzen auch den Puffer gemeinsam).
Fällt ein NLM-Client oder -Server aus, dann müssen bei seinem Wiederanlauf beim jeweiligen Partner Aufräumaktionen gestartet werden. Ein Server muss alle Sperren eines wieder anlaufenden Clients löschen. Ein Client muss seine Sperren beim wieder anlaufenden Server erneut setzen, um den Ausgangszustand vor dem Server-Absturz wiederherzustellen.
Wiederanlaufaktionen können für beliebige zustandsbehaftete Netzdienste erforderlich sein. Sie werden daher bei einem von NLM unabhängigen Dienst, dem NSM (Network Status Monitor) registriert. Der NSM sorgt dann dafür, dass sie beim Wiederanlauf eines abgestürzten Partners ausgeführt werden. Das NSM-Protokoll ist im Programm statd implementiert. Der NLM (lockdsrv, lockdclnt) ist bislang der einzige Dienst, der den NSM (statd) in Anspruch nimmt. Siehe auch die Beschreibung zu lockdsrv und lockdclnt im Abschnitt "Dämonen".