Been working on a print server migration, and with the cutover we started noticing a lot of these errors in the PrintService Operational Log. This log has to be enabled before you will get these errors if you have not done so already.
As part of the setup of this print server, a dedicated disk was attached to the system for the print spool in order to ensure that disk was not a bottleneck in print performance. Windows was left to create the new folder in the new location after changing the path in the Print Management console.
It turns out however that the permissions that Windows by default applies to the newly created folder aren’t actually enough.
Despite this particular error directly stating that the spooler failed to delete the file, the issue actually is that the spooler was failing to create the file first. Therefore once the job had completed the file was not there to delete.
I never found out where the spooler service was putting the files instead, assuming here that it continued to use the spool files. They were not being stored in the default C:\windows\system32\spool folder.
Our solution, was to add in the Authenticated Users group with Full Control permissions to the newly created spool folder.
Monitoring the folder after making this change, which then cleared the error, shows that the spool files are created. The files are created with the Owner being set to SYSTEM. The SYSTEM user had Full Control of the folder anyway. The delete file command seemed to be being run in the context of the user that printed the job. As that user was not the owner, the CREATOR OWNER permission did not suffice for removing the file.
