the problem with local system is, it can't access network shares because local system acts as the computer itself. If you want to have access to a network share with local system, you have to give the AD computer account read rights to the network share. For a client in you domain with hostname "client1" you have to configue read rights on your share permission for "client1$" for example. Not very scaling but doable...
Second option, you can create a so called null session share which grants access to shares without any permission needed. This means a security risk and I wouldn't do this and to be honest, I don't know if this works on server versions above 2008.
The third option, this is the one I would prefer is to define a preferred server where you can configure an account that has read right on your share. If a client connects to this share while software distribution, it will always use this account and you don't have to worry about anything else. You will find a short description how to create a preferred package server here:
Hope this helps...
I will give that a try. I am still confused as to why I can deploy packages from the same share as localsystem and not have any issues yet others seem to cause me grief.
NTFS shares *used to* be able to be accessible to "LocalSystem" by adding the "Domain Computers" account (granted, this is going back quite a while, I hope that's still true).
It's one of the reasons why HTTP-shares are as popular (they're not hard to set up) - because you don't have to worry about NT-authentication slipping you up / "deciding to misbehave" for whatever reason.
You can also run an installer / downloader "in a specific user context" ... which then allows you to access said NTFS share "as that user" instead of "Local System". If you want to script / batch up download commands using LANDesk tech - that's quite doable. See the article here -- How to use PEDownloader.exe to Duplicate / Troubleshoot Software Distribution -- on how to do that (not hard) .
Hope this helps a bit .