Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-20825

Windows installer for v10.3.x+ fails at starting service (works for v10.1.x)

Details

    Description

      Running the 64bit Windows msi installers for either 10.3.15 or 10.4.8 on a Windows 2012R2 box results in the UI hanging on starting services and then failing with the error:

      Error 1920. Service 'MariaDB' (MariaDB) failed to start. Verify that you have sufficient privileges to start system services.

      Running the 10.1.x installer on the same box works fine.

      I am installing the server binaries in the default Windows location in C:\Program Files but the data directory is on a separate drive D:, which is likely to be the issue as it has restrictive file permissions. However I can't seem to identify what permissions are missing: the installer is running as an admin account which does have full control over the data directory, as does the system account.

      During the installation, the MariaDB windows service seems to be created correctly and the Network Service account under which it runs is (automatically) given full access to the data directory, as is the current individual user account. Are there any other permissions that are required before running the installer?

      The attached .err log created during the installation contains several:

      failed on '.\ibdata1'. Can't determine file permissions

      entries.

      I've tried running the installer in verbose mode from the CLI and can supply the full log if necessary. It contains both of the above mentioned errors, which also appear in the Windows event logs.

      Given that the 10.1.x installer works in the same environment, what could have changed in these more recent versions to cause this failure?

      Thanks.

      Attachments

        1. mariadb.err
          4 kB
          Julian Halliwell

        Activity

          Ascending order - Click to sort in descending order
          wlad Vladislav Vaintroub added a comment -

          The "can't determine file permissions" message is bogus, the actual error comes from failing GetDiskFreeSpace() call. Why it is failing, I do not know, it does not fail for me. procmon shows that this call opens the D:\ volume with just a SYNCHRONIZE access, neither read nor write. So there must be something special about ACLs on the D:\ volume on that box. The MSDN documentation says, calling application must have FILE_LIST_DIRECTORY rights on the root directory

          Now, why GetDiskFreeSpace() is called is a different matter. This call does not deliver any vital information to Innodb, it calculates the file system block size, and the only place that value it is used is innodb.sys_tablespaces information schema table. I've fixed the code so that Innodb should start ok. A warning will still be written, but only once

          wlad Vladislav Vaintroub added a comment - The "can't determine file permissions" message is bogus, the actual error comes from failing GetDiskFreeSpace() call. Why it is failing, I do not know, it does not fail for me. procmon shows that this call opens the D:\ volume with just a SYNCHRONIZE access, neither read nor write. So there must be something special about ACLs on the D:\ volume on that box. The MSDN documentation says, calling application must have FILE_LIST_DIRECTORY rights on the root directory Now, why GetDiskFreeSpace() is called is a different matter. This call does not deliver any vital information to Innodb, it calculates the file system block size, and the only place that value it is used is innodb.sys_tablespaces information schema table. I've fixed the code so that Innodb should start ok. A warning will still be written, but only once
          wlad Vladislav Vaintroub added a comment -

          The account which runs the MSI, local system or whatever, is not of any importance. What is important to start the service, is whether account that runs the service , I.e NetworkService has those permissions. The permission in question is mostly likely(at least from reading the docs), is FILE_LIST_DIRECTORY on the root directory of the volume.

          wlad Vladislav Vaintroub added a comment - The account which runs the MSI, local system or whatever, is not of any importance. What is important to start the service, is whether account that runs the service , I.e NetworkService has those permissions. The permission in question is mostly likely(at least from reading the docs), is FILE_LIST_DIRECTORY on the root directory of the volume.
          cfsimplicity Julian Halliwell added a comment -

          Thank you Vladislav, you are quite right. I gave the Network Service "List folder contents" permissions on the root D:\ and it all worked fine.

          Can you just confirm that the fix you've put in removes the need for this permission to be set (it's not completely clear to me from your comment)?

          Thanks again.

          cfsimplicity Julian Halliwell added a comment - Thank you Vladislav, you are quite right. I gave the Network Service "List folder contents" permissions on the root D:\ and it all worked fine. Can you just confirm that the fix you've put in removes the need for this permission to be set (it's not completely clear to me from your comment)? Thanks again.
          wlad Vladislav Vaintroub added a comment -

          Yes, the fix removes the need for that permission. You'll still have 1 warning written into the error log though, but this is a harmless warning.

          wlad Vladislav Vaintroub added a comment - Yes, the fix removes the need for that permission. You'll still have 1 warning written into the error log though, but this is a harmless warning.

          People

            wlad Vladislav Vaintroub
            cfsimplicity Julian Halliwell
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.