Installing and upgrading help

What do I make of that?  Computer error ... glitch ... hickup!

There is data in the mdl_files table that says a file should be there and it's not physically present.  Sooooo ... find that record in mdl_files table and remove it.

Use phpmyadmin or whatever you have of a graphical nature to remove the one record that refers to a file whose contenthash reference is:

4e89d6915f1c57f2e243b889f7da8cdc13741d83

Not that you did anything wrong, but by chance did you rename a file in private files or move one recently?  Just curious ... cause we all know the new file system is 'perfect', right? ;)

'spirit of sharing', Ken

Reponse to @Jeff via regular mail ... for those who might also need clarification/assistance ...

There are references in the DB for those profile pics that point to
filedir/XX/XX/somelongname.  Are you sure the permissions on moodledata/ is set such
that the apache user/group ... on Ubuntu that might be www-data:www-data ... can
read/write files/folders in /moodledata?

The content hash would be unique to each Moodle server ... not the same on ALL.
If you were using the content hash in my response, that was for the other persons
situation/server - not yours.

So what, exactly, does your error show?

Don't use a meat cleaver when a scalpel is needed!!!!   The error you see reports the
folders/files that can be found in your rsync'd backup of your moodledata.   Using
whatever tool you have to browse files in the rsync backup, find the contenthash named
file, copy it out somehere to a file so you can check to see IF it is a f1.png (those
are the profile pic file types/names).  And then see IF one can open that file with
some
image editor.   Reason for the test ... to assure the file itself is valid (not
corrupt).

IF it's a good file, one can copy the contenthash file back into the *production*
moodledata/filedir/somesubdir/somesubdir/contenthash file name.  Since you would be
doing that as root user, make sure the owership/permissions are of the apache
user/group
of your system (again, think those to be www-data:www-data on your Ubuntu system).  And
if a subdirectory/folder cannot be found in that reported path, create it and set
ownership/permissions to that of apache user group.

Example path shows moodledata/filedir/XX/yy/somelongcontenthash and yy doesn't exist,
make a 'yy' directory in XX.  Then move the somelongcontenthash named file into that
directory.

Don't ask me why/how it happened ... can't do a mind meld with servers!!! ;)

However, one potental snafu may have occurred ... that with the use of rsync.
Someone may have tried to do exactly what you asked about doing ... never a good
idea as
the database information/meta data has un-doubtedly changed.   DB info *must match* the
physical filedir/XX/YY/longcontenthashnames.

did you find an answer?  I just moved from hostgator as well and I'm having a similar issue.  

The migration from one server to another ... what was old servers fully qualified domain name?

http://oldhost/

Is that different from the new location/hostname?

http://newhost/

IF this is the case, the URL's pointed to files in Moodle are built by taking the value of the wwwroot for the site thus in the DB one has http://oldhost/....blah/blah/file.   You can check this by placing mouse over the link and look at where it's going to retrieve that file.

When migrating to a new site/domain one must change all links to files.

So ... IF above is true ... do a dump of the DB (ie, get a backup of it before doing the following).  Might also research how to restore your DB should the following not work or you do this in-correctly.   The search and replace has to be 'exacting' and accurate or you'll mess up a bunch of stuff making it harder to fix.

There is a search and replace tool

http://newsite/admin/tool/replace/

You'll see a warning ... that's why the DB backup is important!

Search box: http://oldsite/ - make sure you include the full URL to the old site ... if site was running https then use https://oldsite/ ... make sure to include the trailing '/'.

Replace box: http://newsite/ or https://newsite/ - same thing include the full URL ... include trailing '/'.

That does a search and replace for URL's in a bunch of tables.

Once it finishes, navigate to one of those former errant links to see if that didn't fix it. ;)

This will not fix links one may have had in user created HTML blocks ... those you have to edit manually.

'spirit of sharing', Ken

What see in DB is metadata, so rather than just removing records manually without really knowing what one is doing (never advised) think I'd investigate a little more about the file that's in the DB but does NOT appear to be in moodledata/filedir/

So go to your moodledata/filedir/

Look for a directory: 0a ... change into it.

In side that diretory look for another directory: 32 - change into it.

Now list to see if there is a file by the following name: (command: ls -l)

0a3201a56aac42e796fd5e929bf0c2b8d85ce22d

We don't know what it is but from errors appears to be front page related so ... got any images on the front page NOT generated by theme?

While in moodledata/filedir/0a/32/ issue the following command:

file -b 0a3201a56aac42e796fd5e929bf0c2b8d85ce22d

That will give some brief info about the file.  If that info says something about .jpg or other image info, see what it is.

cp 0a3201a56aac42e796fd5e929bf0c2b8d85ce22d /path_to_web_server/document/root/where_modle/code resides/some.jpg (or .png - whatever file info said it's file type was).

Then, using a browser, go directly to that image ... http://yoursite/some.jpg

Recognize the image?

That same image could be linked in any of the courses.  Then the fun begins to find the course that used it.

'spirit of sharing', Ken