I'm starting a new thread on this to start clean.

1. Files were stored on Amazon AWS and client wanted them off Amazon and on the server.
2. I changed the settings to the local server.
3. I ran the script to pull the files over from Amazon to the local server as that appears to be what it was for.
4. It looked like it ran and all the files showed up - lots of them.
5. Files are instead corrupted as they won't download upon request - start to run but hang. If I FTP them down they won't open either.
6. Switched back to using Amazon to get things running again. Appeared to work again.
7. Tried the move files script again using the script.
8. Now neither Amazon or local files will download - corrupted

The former developer and holder of the S3 account has dropped out of the picture, hard to find.

Ideas to get things back running? DNN 5.6.7, the latest DMX.

Hi John,

I think the first thing is to analyze a couple of cases on your installation to see if it something that can be repaired easily. This is what I'd do:

1. Start by finding a file that doesn't download. Click "Navigate" on the item's menu and make a note of the EntryId in the browser's url bar.
2. Now go to SQL and open table DMX_Entries and find the record with the EntryId noted in 1.
3. Examine the column StorageProviderID. If it's 1 it assumes it is stored on the server hard disk. If it's 3 then it assumes it is stored on S3.
4. Examine the column Entry. The S3 entry will look like [bucketname]|[filename]. The file storage is [path\to\file].

Now you have the keys to examine why it won't download. If it's still S3 it could be because the S3 account no longer works. If it is file based storage then check to see what's up with the file. Is it even there? Note the path begins at portals/[id]/DMX by default. If it's there is it zero length? Try making a copy and setting the extension to what it should be (e.g. docx). Will it open?

Peter

Thanks, Peter. That helped me figure out the structure. The files show the correct size on the user side but FTP shows the file is the wrong size, 4kb. Now that I have the decoder ring it makes analysis much easier. I think the files were pulled from the S3 account. Why the original pull failed I do not know but at least I know what I'm dealing with now - lots of time.