"Not found on server" false error.

[zanb]

Hello fellow Jive Mo-Fo's.

I've been running into an issue lately where a policy will run and attempt to install a script or package but report that it can't be found. Here are the steps I take to verify the file exists:

• Confirmed the file exists on the server/distribution point and isn't damaged.
• Copy the URL to my web browser - downloads just fine.
• Confirmed the octal permissions: 644
• Confirmed the POSIX permissions: CasperRW:_www
• Confirmed the Access Control Entries: CasperRW (Read/Write), CasperRO (Read)
• Confirmed base URL permissions on the server.
• Confirmed the Apache setting "directory listing" is enabled for the base Casper directory

Here's the typical output from the JSS policy:

Error: The package (_PACKAGE_.dmg) could not be found.

or

Error running script: The script could not be found on the server.

So if the file is publicly accessible, why would the JSS complain that the package doesn't exist?

Thank you!

[charles_hitch]

We have been seeing similar errors but we use AFP/SMB DP's. I just assumed they were happening because the user disconnected their ethernet when the policy was running. I haven't spent any time investigating so this is just anecdotal.

[Chris_Hafner]

I've had something similar happen in the past. I'm assuming that your can replicate DPs just fine? Also, can you include a copy of an example log?

[zanb]

Chris_Hafner, that is correct. Files duplicate to DPs without issue. I've even gone so far as to compare MD5/SHA1 hash results of files to make sure they copied successfully. I'm wondering if charles.hitch's theory has some weight to my issue.

Perhaps the clients are attempting to connect to the JSS before they are on the correct subnet. I will speak with my network engineers if they can capture some traffic between the clients and the JSS.

[Chris_Hafner]

Interesting. I suppose that almost anything is possible. However, it would have to change addressing info mid policy as @charles.hitch was mentioning. That said, what is the scope of this issue. Is it happening repeatedly on all machines, on a single machine? Sporadically? I know you must have gone through thinking all of these things but it may give one of us an idea that will help.

I've heard that sometimes downloads can corrupt over HTTP, re-download, fail again and react this way without overwriting the corrupted version of the file. I've seen policies call scripts/files from locations that don't exist on client machines and result in your first error... not the second. So much depends on the policy as well.

One more thought. Have you tried re-creating the policy from scratch, with the same parameters? Usually when the digging starts to get really deep I like to go to the surface and check everything that I KNOW is A-OK again. Just in case!