Upgrade from v7.2.1 to 7.5.1 Fails

OS: Wndows Server 2016
MYSQL 8.0.31
Mattermost enterprise Edition with a professional LIC

When upgrading from 7.2.1 to 7.5.1 the server will not start up. get the following error

{“timestamp”:“2022-12-15 15:19:41.369 -06:00”,“level”:“info”,“msg”:“Server is initializing…”,“caller”:“platform/service.go:157”,“go_version”:“go1.18.1”}
{“timestamp”:“2022-12-15 15:19:41.370 -06:00”,“level”:“info”,“msg”:“Pinging SQL”,“caller”:“sqlstore/store.go:230”,“database”:“master”}
{“timestamp”:“2022-12-15 15:19:41.405 -06:00”,“level”:“fatal”,“msg”:“Failed to apply database migrations.”,“caller”:“sqlstore/store.go:166”,“error”:“open migrations\mysql: file does not exist”}

Not sure what is is checking to see if it has to run migrations, but I have noticed even with the current 7.2.1 it thinks it needs to run migrations but the schema is already at 90.
Here is the DB tSchema


unfortunately I have to say that Mattermost is not supported to be run on a Windows server and the bug you’re posting here is biting everyone using this unsupported configuration with a recent version. There’s probably nothing Mattermost is going to do about that and it seems as if also running the upgrades manually does not fix it (as you can see).
Are you able to migrate to a supported (Linux) platform?

The original problem has been fixed in Use path rather than filepath for embedded files by noxer · Pull Request #21896 · mattermost/mattermost-server · GitHub. It has not been released yet. I guess it will be in the next release.
I don’t know if it will be enough to fix the database, though.

1 Like

This fix is currently scheduled for v7.7 (January) release.

1 Like

Hi @tbielejeski ,

Mattermost 7.7.1 has been relased now - care to try the upgrade again to see if it fixed your issue as anticipated?

So it did seem to take care of the db migrattions issue but there still seems to be an issue parsing out the log file path from the config file. the only value that seems to work is a “.”, if I do a path like “.\logs” it will blow chunks saying l is not valid

And I think specifying the path as ./logs or .\\logs also does not work, right?


I am working remotely at this time.

Alright, thanks! (edited your post to remove sensitive data, no worries, was just me :slight_smile: )

@plusmid to the rescue, please!

Greetings. So I took a look at how the server processes log paths. If FileLocation is not specified the server tries to find a logs folder in one of the parent directories of the working directory and then join it with mattermost.log.
I found an issue with how we configure the logger. Since \ needs to be escaped (but isn’t in that case), the logger config becomes invalid. The only working option would be to provide a simple filename (like mattermost.log), which will create the log file in the current working directory. Double-escaping doesn’t help in this case because the paths are “cleaned” from duplicate path separators.

Ticket: [MM-49849] - Mattermost

And you do not allow / as a path separator in the library/application? Windows supports that nowadays:

C:\Users\Alex>cd c:/users/alex


@agriesser Yeah, we’re already converting the path before the escaping issue. No chance there.

Alright, thanks - I guess that’s a good compromise anyways, since the db migrations are now running the only issue left is the logfile location which cannot be specified; is that something you can live with, @tbielejeski ?

Yea We can live with logs being in the root folder. Do you plan to fix that issue at for windows ???

Mattermost on Windows is not officially supported and according to @plusmid it’s not an easy fix to get it working here, so I think it will stay like this for the time being.

Oh, it’s a fairly easy fix. It just takes some time to get released. I’ll see if I can write the patch this week.

edit: Doug will tackle this. Thanks.

Oh, awesome - misunderstood you on that then, thanks :slight_smile:

This is fixed via MM-49849 Escape log filename entered in system console by wiggin77 · Pull Request #22141 · mattermost/mattermost-server · GitHub

1 Like

Awesome, thanks Doug!
Will this make it into 7.8?

Yes, the fix will be included in 7.8