In some build environments, the account running package restore does not have access to the shared machine-wide cache folder (eg TravisCI).
When this is the case, the nuget.exe restore fails by throwing an exception, eg:
System.InvalidOperationException: Unable to find version '1.1.6' of package 'Microsoft.Bcl'.
at NuGet.PackageHelper.ResolvePackage (IPackageRepository repository, System.String packageId, NuGet.SemanticVersion version) [0x00000] in <filename unknown>:0
at NuGet.Commands.RestoreCommand.RestorePackage (IFileSystem packagesFolderFileSystem, System.String packageId, NuGet.SemanticVersion version, Boolean packageRestoreConsent, System.Collections.Concurrent.ConcurrentQueue`1 satellitePackages) [0x00000] in <filename unknown>:0
at NuGet.Commands.RestoreCommand+<>c__DisplayClass5+<>c__DisplayClass7.<ExecuteInParallel>b__2 () [0x00000] in <filename unknown>:0
at System.Threading.Tasks.TaskActionInvoker+FuncInvoke`1[System.Boolean].Invoke (System.Threading.Tasks.Task owner, System.Object state, System.Threading.Tasks.Task context) [0x00000] in <filename unknown>:0
at System.Threading.Tasks.Task.InnerInvoke () [0x00000] in <filename unknown>:0
at System.Threading.Tasks.Task.ThreadStart () [0x00000] in <filename unknown>:0
However, adding -NoCache to the command makes the build happily restore all packages from nuget.org. This is an indication that the call to fetch the packages from local cache fails, likely due to the account not having sufficient permissions to access that
I don't think the process should fail entirely when this happens. And even if the process fails, the error message is a bit misleading. It would help if the error message also stated on which source the package could not be found.