The BizTalk File adapter, least permissions required for a Receive Location

Every now and then a questions pops up regarding BizTalks FILE adapter permissions. If a Receive Location is set up to poll a folder where the account used (by default the BizTalk host account) does not have appropriate permissions, the following error messages will be written in the event log.

File transport does not have read/write privileges for receive location "D:\BizTalk\In\".

The Messaging Engine failed to add a receive location "Receive Location1" with URL "D:\BizTalk\In\*.xml" to the adapter "FILE". Reason: "File transport does not have read/write privileges for receive location "D:\BizTalk\In\". ".

The receive location "Receive Location1" with URL "D:\BizTalk\In\*.xml" is shutting down. Details:"The Messaging Engine failed while notifying an adapter of its configuration. ".

Usually, the solution is to just give the BizTalk host account full permissions to the folder and be done with it.

I myself try to never give full permissions to any account as long as it is not needed. It is however more common than not to see applications and users all use the SA login to SQL Server, be local (or domain) admins, and be put as a member in all of the groups used in BizTalk. *shudder*

Anyhow, for the FILE adapter, the first attempt a user does if not going the "full permission route" is to give the account used read+write permissions as so:

This will not work but give the same errors again. Neither will adding the "Modify" permission do any good. It is at this point most users simply click the last checkbox available, giving Full permissions. And voila, it will work!

What one rather should do is go to the Advanced permission properties and add the "Delete subfolders and files" permission which in reality is what is missing. BizTalk has been able to properly read the file, but was unable to delete it, resulting in the error.

Notice that the "Delete" permission is not set. Basically, the account used for reading the files in the folder most likely should NOT have the permission to delete the folder itself, but just the contents inside of it.

Be careful though! While experimenting, I noticed that if I had correct permissions according to the screenshot above, but removed for example the "Write extended attributes" permission, the Receive Location would NOT read the files in the folder, neither would it give ANY type of errors or warnings. Everything will in that case look perfectly fine, with the Receive Location up and running, but no files will be read and processed!