Announcement

Collapse
No announcement yet.

Upgrade from 6.1.10 to 7.0.1 fails because of permission denied

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Upgrade from 6.1.10 to 7.0.1 fails because of permission denied

    Hello, I updated from 6.1.8 to 6.1.9, after that to 6.1.10 without problems. When trying to update from 6.1.10 to 7.0.1 I get a permission denied for the upgrade zip-Archive. No hint in log files, message from Plesk:
    • Current version is 6.1.10. Downloading...Error: Permission denied for data/upload/upgrades/615c9c34036e6efa5.zip
    I set the permissions for data folder as in documentation to 775.
    On other server I neither had that problem.

  • #2
    in config.php

    'defaultPermissions' => [
    'user' => 'xxxxx',
    'group' => 'xxxx'
    ],

    change it to website owner/group ?

    Current version is 6.1.10. EspoCRM will be upgraded to version 7.0.1 now. Enter [Y] to continue. y Downloading... Upgrading... This may take a while..........PHP Warning: array_keys() expects parameter 1 to be array, int given in public_html/application/Espo/Core/Utils/Config.php on line 303 Error: Could not read config

    Comment


    • #3
      It looks like this:

      'defaultPermissions' => [
      'user' => 10022,
      'group' => 1003

      Do I have to change anything there. I do not understand that.

      Comment


      • #4
        I saw, that in another installation there is a config-internal.php, in the mentioned one in this post, it is not.

        Comment


        • #5
          Yuri mention : sudo -u www-data php command.php upgrade

          but you need find who is your web user/group..

          my production environment have :

          'defaultPermissions' => [
          'user' => 9011,
          'group' => 9011
          ],

          on my computer, i have put another value.

          Comment


          • #6
            This is all very strange. I upgraded several installations, localhost environment as well as production installations on shared hosting.
            Some created config-internal.php, some not. The one from this post, that did not upgrade, was the only one, that had in the config.php 'defaultPermission' and Apache user and group.
            On upgrading permission was denied, no folder could be created in data/upgrades.
            As the other installations did not have the lines with defaultPermission...., I deleted these lines in the mentioned installation config.php. After this the upgrading worked.

            I upgraded with CLI.

            Comment


            • redgular
              redgular commented
              Editing a comment
              Thanks. This worked and 7.0.3 was installed perfectly.

              "I deleted these lines in the mentioned installation config.php. After this the upgrading worked."

          • #7
            I also can't update to 7.0.1. My permissions in /data/config.php is:

            'defaultPermissions' => [
            'user' => 33,
            'group' => 33
            ],

            What do these numbers mean? Permissions are usually 3 digits... like 775 or 664, etc. Are these octal permissions. I never understood octal permissions.
            Last edited by dev77; 10-06-2021, 02:40 AM.

            Comment


            • shalmaxb
              shalmaxb commented
              Editing a comment
              As I wrote in the post before, for me it worked, when I commented these lines out and the upgrade worked. I don`t know, if this interfers in any other place, but so far not.

            • yuri
              yuri commented
              Editing a comment
              These are GIDs. 33 is an ID. You can find a corresponding value in /etc/passwd

              Important: when you migrating to another server these values should be fixed in the config. It's described in our docs.

          • #8
            it worked, when I commented these lines out... I don't know, if this interferes in any other place
            I'll wait until the developers figure out all of the update bugs in 7.x. It is not a good practice to comment out config code because most often it will 'hit' you sometime in the future and it will be difficult to recover.

            Comment


            • shalmaxb
              shalmaxb commented
              Editing a comment
              I agree with that, but I have one installation, that has to run and I did not want the hassle to downgrade.

          • #9

            I have one installation, that has to run
            Me as well. The upgrade totally corrupted my installed 6.1.9 version so I had no choice but to grab the backup "dump" of my database and reinstall the entire 6.1.10 system from where they keep the older versions. Since then I've tried to upgrade to 7.x but it would not install. At least it didn't corrupt. Obviously there are some major issues with the upgrade to 7.x so it is best to just wait it out until we see 7.1 roll out or if we get specific instructions of how to do the upgrade.

            Comment


            • yuri
              yuri commented
              Editing a comment
              There's no that issue after 7.0.1 anymore. Please no need to use "major issues" w/o proves. Thanks.

          • #10
            The only problem is this

            the defaultPermissions is read from config.php
            chmod for file/directory is do by default (755, 644 if not forget, it's a constant in class)
            for user/group is skipped as you see below

            There are certainly somewhere who have bugged with this user/group value.. or maybe a old value..

            PHP Code:
             /**
            * Set default permission.
            */
            public function setDefaultPermissions(string $pathbool $recurse false): bool
            {
            if (!
            file_exists($path)) {
            return 
            false;
            }

            $permission $this->getRequiredPermissions($path);

            $result $this->chmod($path, [$permission['file'], $permission['dir']], $recurse);

            if (!empty(
            $permission['user'])) {
            $result &= $this->chown($path$permission['user'], $recurse);
            }

            if (!empty(
            $permission['group'])) {
            $result &= $this->chgrp($path$permission['group'], $recurse);
            }

            return (bool) 
            $result;

            Comment

            Working...
            X