If two files uploaded by different users used the same key (ie the server stores the key) then you have no security anyway.
If you can detect that two files encrypted with different secure keys are the same then you are similarly screwed.
If you can detect that two files encrypted with different secure keys are the same then you are similarly screwed.
On the user's account you would then store a list with keys for each file. Before this list is stored or updated on the server, it is encrypted on the client-side with the user's password, so that the server cannot retrieve this information.
Of course, the security with such a scheme is somewhat lower than with "traditional" encryption, as you can find out who shares a given file. But the advantage of this is that you are still able to block particular files, if, e.g., required to do so by law.
That doesn't require that a server know the key; it only requires that those parties exchange a shared key in advance. It's no different than, i.e., a PSK WPA network password, or a shared encryption key on a workgroup document.
You could still use a service like Dropbox as a reliable offsite backup, while doing all your crypto locally. Think of it as the "availability" service to complement your local policies that insure integrity and confidentiality.
The problem is that Dropbox can't offer seamless encryption while still having lazy file sharing.