ASSETMAP references a file that is not in the folder
The index names a file, and the file is absent. This is the most common way an incomplete delivery announces itself.
The message you saw
ASSETMAP references "..." (urn:uuid:...) but the file is not in the folder.The file ... for an asset in the asset map cannot be found.The asset ... is missing.The first line is our browser check, code missing-file. The second is dcpomatic2_verify on the command line and the third is the DCP-o-matic Player, both reporting libdcp's MISSING_ASSET.
What the message actually proves
The ASSETMAP is intact and readable, which rules out the worst cases. What is missing is the thing it points to.
That distinction matters, because it tells you the package was assembled correctly and damaged afterwards. Assembly errors produce broken indexes. Transfer errors produce indexes describing files nobody copied.
Where files get lost
Copies that ran out of space are the leading cause. A drive fills while writing the largest reel, the copy reports an error nobody reads, and every small file around it arrives intact.
Selective copying is next. Somebody moves what looks like the important material and leaves behind a subtitle asset or a second reel, particularly when the package has been sitting in a folder alongside unrelated files.
Case sensitivity catches cross-platform deliveries. A package authored on a case-insensitive Mac volume and read on a Linux server will fail to resolve a path whose capitalisation changed in transit.
Working out what to ask for
Note the filename in the message rather than the UUID, since that is what the sender will recognise. Ask for those specific files instead of the whole package.
Then verify the whole thing again once they arrive. A delivery that lost one file frequently lost more, and a second pass costs minutes.