XenForo can leave a forum fully visible while blocking ordinary members from starting threads or posting replies inside it. You do not need to make the node private, and doing so would solve a different problem by restricting who can see it.
The clean setup lives in the node permissions for the forum you want to freeze. Keep View node available to the people who should still read the archive, then control writing separately through Post new thread and Post replies.
This is where XenForo’s permission hierarchy matters. Registered should normally remain the common base group, while secondary groups grant exceptions for staff or other people who still need to publish.
Leaving one of those permissions untouched creates a different kind of forum. An announcements area may deliberately block new threads for members while still allowing replies beneath staff posts. An archive normally needs both posting permissions disabled because the goal is preservation rather than controlled participation.
Do not use a private node for this job. XenForo’s private setting affects View node, so members without an explicit viewing grant lose access to the forum altogether. A read-only forum should stay visible to the people already entitled to see it and remain open for normal reading.
Avoid Never for the Registered group unless you truly need an overriding denial that no secondary group can escape. A normal No lets another group receive Yes, which is exactly what you want when moderators, administrators, or an editorial group must keep posting.
Role-based access control assigns permissions to roles and lets users acquire those permissions through role membership. The underlying model is well established in role-based control with explicit permission inheritance. XenForo user groups give you the same useful administrative habit of granting publishing rights to a role instead of copying exceptions across individual accounts.
Set Post new thread and Post replies to Yes for the staff group that should continue publishing in that node. Use the narrowest group that matches the job. An announcements team does not need broader moderator powers just because its members can create announcement threads.
Individual user permissions also work, but they become tedious when several people need the same exception. A dedicated secondary group is easier to inspect later and less likely to leave forgotten one-off permissions scattered across accounts.
Test with an ordinary member and a permitted staff member. The member should still see the forum and existing threads but should not receive controls for creating a thread or adding a reply. The staff account should retain those controls in the same node.
If either account behaves differently, run node-specific permission analysis before changing more settings. Multiple group memberships, an old direct-user override, or a child-node customization can produce a result that is not obvious from the Registered row alone.
Archived support forums, completed competitions, policy discussions, and old project areas often need stronger preservation. Review Edit own post, Delete own post, thread-editing permissions, and the configured editing or deletion time limits instead of assuming a posting ban covers them.
Be careful with numeric editing limits. XenForo resolves numeric permissions by using the highest applicable value, so a smaller number added at one level may not reduce a larger value inherited from another group. Permission analysis is safer than guessing when an edit window refuses to shrink.
Locking individual threads can stop ordinary replies inside those threads, but it is not a substitute for node permissions when an entire forum must become read-only. A forum containing hundreds of old threads is cleaner to control from the node than by touching each thread separately.
Add-ons deserve one final check. XenForo add-ons can introduce additional permission types, and publishing features outside ordinary forum posts may have their own controls. A section is only truly frozen when the actions available through the installed feature set match the access policy you intended.
The clean setup lives in the node permissions for the forum you want to freeze. Keep View node available to the people who should still read the archive, then control writing separately through Post new thread and Post replies.
This is where XenForo’s permission hierarchy matters. Registered should normally remain the common base group, while secondary groups grant exceptions for staff or other people who still need to publish.
A real read-only forum blocks two different actions
Setting Post new thread to No stops members from opening new discussions in that forum. It does not stop them from replying to threads that already exist. For a genuinely read-only section, set Post replies to No as well for the Registered group on the same node.Leaving one of those permissions untouched creates a different kind of forum. An announcements area may deliberately block new threads for members while still allowing replies beneath staff posts. An archive normally needs both posting permissions disabled because the goal is preservation rather than controlled participation.
Do not use a private node for this job. XenForo’s private setting affects View node, so members without an explicit viewing grant lose access to the forum altogether. A read-only forum should stay visible to the people already entitled to see it and remain open for normal reading.
Avoid Never for the Registered group unless you truly need an overriding denial that no secondary group can escape. A normal No lets another group receive Yes, which is exactly what you want when moderators, administrators, or an editorial group must keep posting.
Role-based access control assigns permissions to roles and lets users acquire those permissions through role membership. The underlying model is well established in role-based control with explicit permission inheritance. XenForo user groups give you the same useful administrative habit of granting publishing rights to a role instead of copying exceptions across individual accounts.
Staff access needs an explicit publishing exception
People often discover the staff problem after making the forum read-only. Their moderators are still members of Registered, so the same node-level No applies to them unless another applicable group supplies a Yes.Set Post new thread and Post replies to Yes for the staff group that should continue publishing in that node. Use the narrowest group that matches the job. An announcements team does not need broader moderator powers just because its members can create announcement threads.
Individual user permissions also work, but they become tedious when several people need the same exception. A dedicated secondary group is easier to inspect later and less likely to leave forgotten one-off permissions scattered across accounts.
Test with an ordinary member and a permitted staff member. The member should still see the forum and existing threads but should not receive controls for creating a thread or adding a reply. The staff account should retain those controls in the same node.
If either account behaves differently, run node-specific permission analysis before changing more settings. Multiple group memberships, an old direct-user override, or a child-node customization can produce a result that is not obvious from the Registered row alone.
Freezing new posts does not automatically freeze old content
Stopping new threads and replies handles future publishing. It does not necessarily turn every existing message into an untouchable record. Members may still have permission to edit or delete their own earlier content, depending on the rest of your forum permissions and editing limits.Archived support forums, completed competitions, policy discussions, and old project areas often need stronger preservation. Review Edit own post, Delete own post, thread-editing permissions, and the configured editing or deletion time limits instead of assuming a posting ban covers them.
Be careful with numeric editing limits. XenForo resolves numeric permissions by using the highest applicable value, so a smaller number added at one level may not reduce a larger value inherited from another group. Permission analysis is safer than guessing when an edit window refuses to shrink.
Locking individual threads can stop ordinary replies inside those threads, but it is not a substitute for node permissions when an entire forum must become read-only. A forum containing hundreds of old threads is cleaner to control from the node than by touching each thread separately.
Add-ons deserve one final check. XenForo add-ons can introduce additional permission types, and publishing features outside ordinary forum posts may have their own controls. A section is only truly frozen when the actions available through the installed feature set match the access policy you intended.
