"The specified user or domain group was not found" is one of those Windows Server permissions errors that shows up in a lot of different contexts, from setting NTFS permissions on a folder to configuring IIS application pool identities, and it almost always comes down to the same root cause: the security identifier a system remembers no longer resolves to a real account.
The most common cause: an orphaned SID
When a user or group is deleted from Active Directory, anything still referencing that account by its security identifier, or SID, is left pointing at nothing. Windows shows this as a mangled looking entry, sometimes literally displaying the raw SID string instead of a name, and any attempt to edit or resave permissions on that object throws the "specified user or domain group was not found" error until the orphaned entry is removed.
How to find and remove it
In the folder or object's Security properties, look through the permissions list for an entry showing a SID rather than a readable account name, or one marked as unresolved. Select it and remove it, then reapply permissions cleanly with the correct current accounts. For IIS, the same idea applies to application pool identities and site level permissions, where an old service account SID can get stuck the same way.
If it is happening across many objects at once
This is usually a sign that a bulk cleanup of stale AD accounts happened without also cleaning up file share or application permissions tied to those accounts beforehand. A script based approach using PowerShell to enumerate ACLs and flag unresolved SIDs across a whole file share is far more practical than fixing them one folder at a time, especially on a server that has accumulated years of permission changes.
If your file shares or Active Directory environment have accumulated years of permission sprawl like this, a proper cleanup and modernization project usually pays for itself quickly. Our managed IT services team can help. Get in touch if that is what you are dealing with.