OK, process of elimination:
If you can make a change directly to a table but not through a form, ...
a. If it is a monolithic database, then the problem isn't file security on the whole database.
b. If it is a split database, then the problem isn't file security on the back end.
Which leaves the probability that something has the form's "AllowEdit" and the other "Allowxxxx" properties set false. Which doesn't occur by accident as they are rather obscure settings. So... were you playing with code that might have attempted to alter these "Allowxxxx" settings? If so, that's the first place I would look.
Since you said "Any form" that implies multiples? If so, do you have some code that you use from a global module to prep a form for use? Look there if you have it.
It is not uncommon to find that a database corruption has locked things up. So... have you tried a Compact & Repair operation?
Then there is this question. It is not an attempt at being facetious. How do you know it will not allow entry? What is the symptom? Error message? Controls non-responsive? Controls won't accept focus? What happens?
As an experiment, can you start from scratch and build a form that allows an update of something that some other form cannot update? Try it on a copy of the miscreant database to see what it will let you do.
