Just to clarify, I'm trying to Pull from a UNC share on the same box as my ePO. I set the Source Site up via server settings and credentials tested OK; I can also check-in packages from there with no problem.
I also created a test Distributed Repository, and pointed it to the share, and replicated. This copied over the contents of the master repository, along with the sitestat and catalog files, which means the Pull task was able to communicate with the share and list all the files available for Pulling. Of course the new DAT wasn't included because it wasn't replicated, it was already in the folder.
OK, clear as mud now!
Found a decent workaround to complete scheduled DAT Pulls for a closed network with multiple ePO servers. Creating a new Source Site under Server Settings doesn't allow you to drop new DATs into them and make them available for your ePO servers to Pull from, because they don't have the sitestat.xml and catalog files that tell the Master Repository what's in the Source Site folder/location.
The current DAT and sitestat.xml and the catalog file live on the ePO server in the DB folder, along with the current, previous and evaluation folders. As long as you copy the current DAT and its associated sitestat.xml and catalog file to an accessible location, your ePO servers can schedule a Pull from these locations. You could script a daily or weekly robo-copy that downloads the DAT to a local share and ePO can Pull it from there.
All we need to is check-in the new DAT or engine on the Master ePO server (once) and it updates the local DB folder; along with the sitestat.xml and catalog files. Then your script copies the DAT and the sitestat.xml and catalog files from the master ePO server into a local share and the then the ePO server can run a 'Pull' to get the latest DATs.