That’s not what OP said they wanted:
I want to be able to remove illegal uploads when they get reported
Besides, OP’s own advice to upload manually encrypted files runs directly counter to this
Exactly. That’s why I don’t understand the reasons OP is giving for not having E2EE
it is not end to end encrypted. The server can read what is stored, on purpose.
I want to be able to remove illegal uploads when they get reported, child sexual abuse material above all. A server that cannot see its own contents cannot act on those reports, and I am not willing to run one that cannot.
How would end-to-end encryption prevent you from taking down content that gets reported? Uploads must have an associated ID, in addition to the key needed to decrypt the data, that people could report and that you could then use to identify what data to remove. Because otherwise, how could the server determine what data to deliver to a user who wants to download files that have previously been uploaded to your service.
Surely your strategy for dealing with this kind of thing doesn’t involve manually reviewing every file that has been uploaded to your server, or even just the subset of files that get reported. If it does, then people uploading manually encrypted files, as you suggest they do, would be as big an impediment to you taking down illegal content as automatic end-to-end encryption
An ID is needed to determine if the content exists and a key is needed to decrypt it.
Somebody making a report that there is illegal content in OP’s server, but provides neither an ID nor a key, quickly ceases to be actionable. At a minimum you need the reporter to provide upload IDs.
But even if the reporter supplies the IDs, the report may not be actionable by your standard: The uploader can easily encrypt the uploaded data, as OP themself recommends.
So OP needs a policy on what to do when they cannot inspect the content of a reported upload, regardless of wherever or not their service provides E2EE