No one else has run across this issue?

Is there a pattern to this ? i.e. can they upload once and then not the second time ? Does it only happen on multiple doc uploads or single ones ? You don’t have terminal services running on the same box do you ? Also, what anti-virus are you running on your front end web  servers ?

You could also try increasing the threads in your web garden (you only need this if something is causing iis to keel over – you can keep one thread going while the other recycles buying you time to see whats making the threads die)

Also, check that your sql server  has enough space on the drive containing its content db’s (bizarrely it gives this error when you are out of sql storage !)

I have begun to experience this same problem. I first noticed it
when one of my users  was trying to create a document workspace via
Excel. It would allow me to create the workspace, but only if the
file size was below 50k, anything larger failed. Then I tried
uploading to a document library, same thing, anthing larger than 50k
failed with "server busy" / "form validation error".

I checked SQL Server, plenty of HD space and DB's set to autogrow
with no limitation. I then checked SQL server  log files.
Ahhah. "Out of Memory" error. Restarting the SQL Server services
would take care of the problem for a few hours, but then, error
again.

There have been no changes to SQL Server or Sharepoint Server.
Anyone have any ideas?

This is nearly always a problem with SQL not being able to write to the database. Either your close to being out of disk space on your SQL server, or there isn’t enough RAM or there is too much latency in getting the packets to the SQL server  in time to build the file in the memory space of the transaction log file – something like this. It’s likely not an issue with your SharePoint server.

The file upload issue seemed to coincide with our organization's
transition to Common Access Card (CAC) authentication. Just thought I
would throw that out there for additional information.

The SQL tech told me
it was a problem with the extended stored procedure in SQL called
sp_AOcreate. There is a problem in SQL SP3 with the odsole70.dll
that causes memory leaks. He told me that that is a DB on the SQL
server that is calling the sp_AOcreate stored procedure and then not
calling the sp_APdestroy procedure to destory the memory it
consumed. Therefore, the memory usage in SQL grows until it runs
out, preventing SharePoint from being able to upload. The
SharePoint tech confirmed that it was NOT SP using the stored
procedure.

Solution would be to upgrade SQL to SP4 or move the SP DB's to
another SQL server.

Due to my production environment, I am unable to upgrade to SP4,
therefore I am working on just moving the DB's.

We are running SP4, and moving the DB to another is not an option.

I sent all the comments to our sysadmin guy, and he ruled out all options but the packet latency issue. How do I solve that?

As a filler to what he wrote - We
are in a SQL Clustered and Web NLBed environment. The Cluster is
running at SP 4 and the NLB front ends have all the latest and
greatest patches. The load on the whole system never exceeds 8%
unless we're performing backups. We run multiple portals in this
installation instance and none of the other portals seem to be having
this difficulty, or none have reported it anyway. His portal  is also
the largest with a combined total on his DBs (just the 3 standard) of
over 168GB. According to Roger's users  the problem is sporadic and
across multiple sites. I believe that the size of the DB combined
with the fact that the network at our location, not controlled by us,
hiccups quite often, can be the cause of the issue. I do have
timeouts set to max on the sessions so not sure what else to do and
have optimized everything as much as I can and not sure of anything
else which can be done.

We were experiencing random upload issues as well and it turned out to be a bug in our load balancer software. We upgraded the software on out BigIP F5 load balancers and the issue went away.