Yes, I followed that line of reasoning. I even changed the services to run as one of the domain administrators. None of those made any difference. Just so you can perform a sanity check on me, here is what I did: 1) When I was able to ascertain that indeed it looked as if permissions were the root of the issue, I had noted in a previous support forum message a user or FAQ noting the need to change the services as far as which entity they were. So I did just that, changed the services to a different domain entity. Restarted the services, then check again, still not able to perform the task. Kept getting that more generic of messages related to potentially not having permission. 2) I went through and double checked the UNC share permissions, the folder security permissions, etc. to confirm they matched and granted the entity which the TA services were running as did indeed have the correct permissions. To test this I disconnected all mapped drives to the target network folder from the host server on which TA is installed. I created a mapped drive forcing it to use the same credentials as the entity running the services. Sure enough I could use windows file explorer to save and move and delete files through that mapping with no issues, but not when the TA program attempted to perform the function. As a "cross my fingers and hope this works" type of solution I restarted both the TA server and the target server to which I was attempting to save files. Windows file explorer worked just fine, but not any of the TA based program items. I even tried during this period of time to test with the TA server logged in as the same entity under which the services were running. Still no progress. 3) Finally, I added the entity under which the TA services were running to the local computer administrators group of the target system and that solved everything. Not a good choice, but it made it work. It was immediate once that change was made everything related to permissions was solved.
|