This post was originally published here
In the spirit of documenting all possible and imaginary errors, let’s address today a classic one: File transport does not have read/write privileges for receive location “DRIVE:FOLDER NAME”.
This happens more than you may think, and today after finish creating a backup port for testing a new process while I was trying to Enable the File receive location I got the following errors:
File transport does not have read/write privileges for receive location “C:BizTalkPortsIN_POLLING”.
Followed by other similar warning messages:
The Messaging Engine failed to add a receive location “POLLING_FILE” with URL “C:BizTalkPortsIN_POLLING*.xml” to the adapter “FILE”. Reason: “File transport does not have read/write privileges for receive location “C:BizTalkPortsIN_POLLING”. “.
The receive location “POLLING_FILE” with URL “C:BizTalkPortsIN_POLLING*.xml” is shutting down. Details:”The Messaging Engine failed while notifying an adapter of its configuration. “.
Cause
As I said before this is a classic error, the reason is quite obvious and the error message clearly identifies the origin of the problem.
The problem is that the user that is running the BizTalk Server host instance(s) don’t have read/write privileges in that specific folder.
Solution
To solve this problem, you need to give readwrite privileges for the user that is running BizTalk Server Host Instance, in my case “BTSHostSrvc”, into that specific folder. For that you need to:
- From the file system, access to the folder in question and then right-click on the folder and select the “Properties” option;
- If attribute “Read-only (only applies to files in folder)” is enabled (selected), disable it (unselect);
- Then go to the “Security” tab and then click “Edit…” button and then “Add…” button
- Search for the user that is running the BizTalk Server Host Instance and then click “OK”;
- For that specific user give read and write access;
- In my case, because this was/is a “BizTalk process” folder, I gave “Full control”
- At the click “OK” and “OK” once again.
Once you give access to the user this classic problem is going away… until the next time!
