This is often because the webparts are attempting to access lists or areas of the site that the current user is not permitted to access. This can be resolved by ensuring that the webpart code to access the content is run with elevated user permissions as the System Account. This can be achieved by using the following block of code;
SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPSite site = new SPSite(web.Site.ID))
{
// implementation details omitted
}
});
Also, if your already using this elevated approach make sure that any lists or items that you are referencing come from a web object that was instantiated within the elevated block. Otherwise, the elevated security permissions are not applied to objects your are working with that were created beforehand.
Finally, to ensure you understand exactly what content is causing the permissions error, take the correlation id that the user is shown in the access denied page. Visit the ULS logs in
C:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\14\LOGS
And open the log file that was generated at the time of the access denied event. Search for the correlation id and you will find a series of log messages which describe exactly which piece of content provoked the access denied message.
Finally, consider installing ULS Log Viewer as it makes the task of reviewing the ULS logs much easier and can display real time feedback on what's happening with the site during a repetition of the problem.