While troubleshooting an issue for a customer of mine recently I got to learn about a dark corner of the MOSS 2007 Publishing infrastructure that doesn't seem too well documented. The problem they were having was that users who were members of the "Designers" SharePoint group were encountering errors when using the Site Content and Structure page (_layouts/sitemanager.aspx, accessed via the Site Settings -> Manage Content and Structure menu) to move publishing pages from one subsite to another within the site collection.
The process would always start out promising, with a progress display on the LongRunningOperationProgress.aspx page, similar to this:
But it would end unsuccessfully, with a final message like this: 
The frustrating thing about the situation is that SharePoint was trying to help – there is that tantalizingly named button there "View Logs", but alas none of the users encountering the problem could actually view the logs – when they would press that button they would an Access denied message.
So, we actually had two problems – first of all, the pages could not be moved, and secondly the people trying to troubleshoot things couldn't see the log messages. The first problem turned out to be caused by insufficient permissions for the user performing the move operation at certain points within the site hierarchy. This was easy to pinpoint once I could actually see the log messages.
The remainder of this post examines the second problem of getting at these log messages. In my case, I didn't even know where these log messages were actually stored. After a little digging around I found that I should be looking at Site Settings -> Content and structure logs (_Layouts/SiteManager.aspx?lro=all). So I got a Site Collection Administrator's assistance and began exploring.
When you get there, you'll see something like this:
It may not be very obvious from the above screen shot, but the view of the log messages is not very usable. Imagine if there are several hundred log messages (as there were in my customer’s production environment) – there's no way to filter or sort or export these messages… I figured that is this view was really backed by a plain old SharePoint list somewhere. I just needed to find it and then I should be able to do what I needed to drill down on details for the issue I was investigating. After some searching on the internet, I found these posts about Long Running Operations (Part I and Part II) that provided what I needed. Thanks txs8311, whoever you are! There is a hidden list called the "Long Running Operation Status" list that is created under the root site of site collections that have the Publishing feature enabled. You can see this and other hidden lists if you open the root site in SharePoint Designer:
In my situation, I could not use SharePoint designer to get to the list on the customer's site, so instead I just typed the list's URL (http://<portalURL>/Long%20Running%20Operation%20Status/) into the browser, which showed me a view like this:
Now I finally had the tools I needed. I created a new private view that showed all of the columns I was interested in, and that filtered just show items that had "Errors Encountered" begins with "<" (that field contains an XML string with details when things go wrong) and that sorted on Created date descending.
While I was at it I also took a look at the permissions on this list. They are not inherited, and they only account that has access is the web application's application pool account. I guess this would explain why the users were not able to view their own log messages, but site collection administrators could. I think it would be safe and useful to grant Designers and Site Owners and Site Managers groups Read permissions on this list. I tried it out in my test environment and it works nicely. The "Content and structure logs" viewer even filters the list of log messages only show those of the user. I don't know why it doesn’t setup that way from the start.
Hopefully this saves someone some head knocking.