Magento backup problem


Mode switching
So I run that commend, doesn’t seem to do much in my case.

Ownership checks
That’s what I got after both commends.

magento@seampress:/var/www/html$ ls -la /var/www/html/
-bash: fork: Cannot allocate memory
magento@seampress:/var/www/html$ ls -la /var/www/html/var/
total 60
drwxrwsr-x 10 magento  www-data 4096 Mar  4 19:46 .
drwxr-xr-x 14 magento  www-data 4096 Mar  4 14:52 ..
drwxrwx---  2 magento  www-data 4096 Mar  4 11:37 backups
drwxrwsr-x 13 www-data www-data 4096 Mar  4 17:15 cache
drwxrwsr-x  3 www-data www-data 4096 Feb 28 12:47 composer_home
-rw-rw-r--  1 magento  www-data  126 Feb 27 11:19 .htaccess
drwxrwsr-x  2 www-data www-data 4096 Mar  4 15:29 log
-rw-rw-r--  1 magento  www-data   14 Mar  4 10:58 .maintenance.ip
drwxrwsr-x 19 www-data www-data 4096 Mar  4 14:06 page_cache
drwxrwsr-x  2 www-data www-data 4096 Mar  4 16:54 report
-rw-rw-r--  1 magento  www-data 6557 Mar  4 19:46 .setup_cronjob_status
drwxrwsr-x  2 www-data www-data 4096 Mar  4 15:17 tmp
-rw-r--r--  1 magento  www-data  148 Mar  4 19:46 .update_cronjob_status
drwxrwsr-x  3 www-data www-data 4096 Mar  4 15:16 view_preprocessed

The first error “cannot allocate memory”. While installing all the modules from Unero theme I also got one line with something about memory allocation.

Frontend error
I guess I’ll raise a ticket there. The MGS module is a part of the Unero theme and I believie an important one as their documantaion says:

Module MGS_Mpanel is indispensable

Backend error
Another problem here

magento@seampress:/var/www/html$ bin/magento composer update
  Command "composer" is not defined.
magento@seampress:/var/www/html$ bin/magento setup:upgrade
-bash: fork: Cannot allocate memory

Also I nearly forgot that I’ve put down one note I got while installing those modules which was related to modes of Magento.

NOTE: Manual static content deployment is not required in "default" and "developer" modes.
  In "default" and "developer" modes static contents are being deployed automatically on demand.
  If you still want to deploy in these modes, use -f option: 'bin/magento setup:static-content:d
  eploy -f'

and I believe that somewhere around content deployment I got that memory notifcation I mentiond earlier.

Too conclude, I’m rather lost in this. I’ve done backups and I’ve got them downloaded. Maybe there is an easy way to get myself clean Magento start to try it again? If not I guess I will be trying to fix mess I got here :wink:


Ownership Checks

Everything looks good here

Backend Error
I typo’d the composer command. I’ve updated my reply.

"Cannot allocate memory" Error
This error message means that you don’t have enough available PHP memory to execute the command. It’s a common issue on systems with 2GB or less of memory. Ideally a minimum of 4GB is the recommended allowance (2GB for PHP and 2GB for everything else). If your system does already have a minimum of 4GB of memory, then you need to check your .htaccess files.

Open .htaccess

nano .htaccess

Use your Arrow or Page Up/Down keys to work your way down the file and find a line containing memory_limit. You’ll actually find 2 instances in the file, one under mod_php5 and one under mod_php7. Just go ahead and change the instance under PHP 7.

Replace this:

php_value memory_limit 756M

with this:

php_value memory_limit 2G

To save your changes, press Ctrl+X . Then you’ll be asked if you want to save your changes. Simply Type “Y” and then Enter to do so.

Then re-run the below commands:

  1. composer update
  2. bin/magento setup:upgrade

Composer did update but after I put second command it showed this:

magento@seampress:/var/www/html$ bin/magento setup:upgrade
SQLSTATE[HY000] [2002] No such file or directory

Which basically is the first sentence from my current web error.
Maybe I should simply rollback to Magento without my theme and try it again? Or is it pointless?


I only have 2 suggestions and 1 longshot for this issue:

Disk Space
Unable to create required folder/files due to inadequate disk space. This sometimes happens when your error logs get out of hand. Might be worth a check. Run as any user from any directory:

df -h

Example Output

Filesystem      Size  Used Avail Use% Mounted on
udev            2.0G     0  2.0G   0% /dev
tmpfs           396M   41M  356M  11% /run
/dev/vda1        78G  5.5G   72G   8% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
/dev/vda15      105M  3.4M  101M   4% /boot/efi
tmpfs           396M     0  396M   0% /run/user/1000

The Filesystem with the largest drive (e.g. 78G) is your disk space. Just check that the "Use% is not 100%. If it is, I’ll give you some tips on what to delete etc…

MySQL Crash
MySQL may have crashed at some point (possibly resource related). Try restarting it. Run as superuser from any directory:

sudo service mysql restart

Hopefully, that’ll jump start everything.

Finally, I found this post that suggests you to “set the database hostname as instead of localhost”. I’m not sure if this:

  • The setting in app/etc/env.php
  • The setting in phpMyAdmin (user/database)
  • or both?

As I’ve had to change this before. Obviously, you could do a rollback as suggested but it might be worth looking at the above 3 things first - For science :slight_smile:



Disk space
This one is fine. I use aroud 11%.

MySQL Crash
I’ve restarted it couple of times now and does’t seem to do much. Although on the front end I don’t get SQSTATE error but the MGS modul one. The back end loads terribly long but it sometimes gets to the point where I can log in. So maybe it did something after all.

Changing it in app/etc/env.php didn’t change anything. And changing the database name via phpMyAdmin is really hard, I only could log in once and it kicked me in few seconds. Also phpMyAdmin shows the same error code as front end did #2002 - No such file or directory.

Am I running into two errors? One being problem with mySQL and php libraries and the second one being problem with MGS module in my theme?

And once again thanks so much for helping me :slight_smile:

Also I’ve just raised a ticket with their support so we"ll see where it gets me


I think I agree, that there are 2 things going on here. The MGS module is definitely one of them, based on that comment I found on Themeforest.

Did restarting mysql give you back access to the backend? Or could you get on there anyway?

If backend is super-slow, it might be regenerating the cache. Or perhaps all the caches are currently disabled? That would definitely kill your load times for sure. You could either enable in System >Cache Management on the backend or via the Command Line Interface. Run as magento user in Magento root directory:

bin/magento cache:enable

You’ll either see:

There is nothing to change in cache status

or something like this:

Changed cache status:
                        config: 0 -> 1
                        layout: 0 -> 1
                    block_html: 0 -> 1
                   collections: 0 -> 1
                    reflection: 0 -> 1
                        db_ddl: 0 -> 1
               compiled_config: 0 -> 1
                           eav: 0 -> 1
         customer_notification: 0 -> 1
            config_integration: 0 -> 1
        config_integration_api: 0 -> 1
                     full_page: 0 -> 1
             config_webservice: 0 -> 1
                     translate: 0 -> 1
                        vertex: 0 -> 1

No problem. Despite the issues, this is how we learn. And hopefully you’ll have the opportunity to pass that knowledge and experience onto others.


I used the code and I got:

Changed cache status:
                        config: 0 -> 1
                        layout: 0 -> 1
                    block_html: 0 -> 1
                   collections: 0 -> 1
                    reflection: 0 -> 1
                        db_ddl: 0 -> 1
               compiled_config: 0 -> 1
                           eav: 0 -> 1
         customer_notification: 0 -> 1
            config_integration: 0 -> 1
        config_integration_api: 0 -> 1
                     full_page: 0 -> 1
             config_webservice: 0 -> 1
                     translate: 0 -> 1
                        vertex: 0 -> 1
Cleaned cache types:

And the back end finally works. :slight_smile: It did load like 10 minutes or so but now it seems that it works pretty much normally. I will try to finish theme installation and see wheter it helps the front end as this one still shows MGS error.

So, I finalazied theme installation via admin panel. I had small problem there, while installing the theme I got the message “Can’t create directory, unable to access” and I ended up creating them manually through FileZilla until it worked. That raises up a qustion wheter all my settings are correct as it seems I simply don’t have all the rights on my admin account, the same problem I got with ticking “Maintanance mode” while making a backup.
And about the front end error I fixed by simply updating the theme. Which is really odd because I updated it as soon as I originally updated files on FTP server. I did it again and it worked. Anyway it works now, so thanks for helping :slight_smile:

1 Like

Sorry for two posts in a row but I think you didn’t see my second edit so here I post it again:

So as I thought I ran into problem with denying access. I tried to upload a logo and again I had to create directories manually via FTP and even after Magento can’t copy the logo (and doing it manually won’t work for some reason). I get this:

The file or directory "/var/www/html/pub/media/tmp/design/file/logo_4.png" cannot be copied to "/var/www/html/pub/media/logo/stores/1/logo_4.png" Warning!copy(/var/www/html/pub/media/logo/stores/1/logo_4.png): failed to open stream: Permission denied

So my question is did you ever ran into similar problem or perhaps know a solution to this? I have all the permissions set in user roles, I made another user, same problem. Don’t know what to do.


Sorry, I never saw your edit.

Glad you got the theme working :+1:

There is a known bug regarding the uploading of logos in Magento 2.3. Check the end of this post (Changing logo in magento 2.3.0). It should be fixed in the next patch (2.3.1) which is due at the end of the month. But the post I’ve linked to explains how to “fix” it in the meantime.

See how you get on with that.


No problem, I’ve already did that. I’m aware it’s not the safest method but I really don’t want to wait for the patch, I’ll keep it in mid and hopefully it will bea easy to revert the changes.
Anyway I am able to upload photos however I got an error afterwards:

That’s my problem from some time. I got same issue while installing theme, was unable to create some directories and did it manually via FTP. So I don’t know what the issue is as I’m pretty sure my admin has all the rights.


Looks like either:

  1. Magento doesn’t have permission to write to the default folder
  2. Magento doesn’t have permission to overwrite the logo_5.png file assuming that file exists already (perhaps owned by another user?)

When you upload via FTP are you using your magento user credentials? If you upload as someone else, it’ll break ownerships.

What output does the below give you?

ls -la /var/www/html/pub/media/logo/default/`

Best case scenario

drwxr-sr-x 2 www-data www-data  4096 Aug 21  2018 .
drwxr-sr-x 4 www-data www-data  4096 Oct 16 13:02 ..
-rw-r--r-- 1 www-data www-data  4211 Jul 17  2018 logo_5.png

Potential issue (wrong owner of existing file)

drwxr-sr-x 2 www-data www-data  4096 Aug 21  2018 .
drwxr-sr-x 4 www-data www-data  4096 Oct 16 13:02 ..
-rw-r--r-- 1 bob      www-data  4211 Jul 17  2018 logo_5.png

The output is:

magento@seampress:~$ ls -la /var/www/html/pub/media/logo/default/
total 12
drwxr-sr-x 2 magento www-data 4096 Mar  4 15:02 .
drwxr-sr-x 4 magento www-data 4096 Mar  6 12:34 ..
-rw-r--r-- 1 magento www-data  514 Mar  4 15:02 logo.png

Which I think is a good one? When uploading via FTP I used magento user.


That looks spot-on. Hmm…

Out of curiosity, can you check that your cron is setup under the correct user. If you were to setup cron under the incorrect user, Magento would try and run tasks as that person resulting in an Ownership issue. Run below as magento user from any directory:

crontab -l

Sample Output (Expected)

* * * * * /usr/bin/php7.2 /var/www/html/bin/magento cron:run 2>&1 | grep -v "Ran jobs by schedule" >> /var/www/html/var/log/magento.cron.log
* * * * * /usr/bin/php7.2 /var/www/html/update/cron.php >> /var/www/html/var/log/update.cron.log
* * * * * /usr/bin/php7.2 /var/www/html/bin/magento setup:cron:run >> /var/www/html/var/log/setup.cron.log

Sample Output (Bad)

no crontab for magento

Then you’d have to check who the cron tasks are setup under than change them so that magento user runs them instead.

Other than that, I’m not sure what else to think of right now - Unless of course it’s a bug I don’t know about.


Well, so it’s set correctly i suppose:

#~ MAGENTO START 40d1b2d83998fabacb726e5bc3d22129
* * * * * /usr/bin/php7.2 /var/www/html/bin/magento cron:run 2>&1 | grep -v "Ran jobs by schedule" >> /var/www/html/var/log/magento.cron.log
* * * * * /usr/bin/php7.2 /var/www/html/update/cron.php >> /var/www/html/var/log/update.cron.log
* * * * * /usr/bin/php7.2 /var/www/html/bin/magento setup:cron:run >> /var/www/html/var/log/setup.cron.log
#~ MAGENTO END 40d1b2d83998fabacb726e5bc3d22129

Chcecked out of curiosity and still get the same error when trying to upload logo again. Although I get different error when choosing previously uploaded logo. I get this one:

header_logo_src does not contain field 'file'

Which is the same one I got before editing core code. So I don’t know. Am I to wait for the patch? I’m out of ideas at this point as I couldn’t find any anser in the web.


I take if you’ve gone through these?

Either way, it definitely seems more like a “bug” rather than “user error”.

Can't create a system backup

I kinda did. I went through A and did upload files from the package I found there but it only crashed my page so I had to upload backup I had done before. The B is different I don’t get the “infinite loading screen” as they did. And as of C I don’t really get that message anymore, I don’t know wheter it was one time thing but it generally is not the issue.

Do you think it’s worth to try reinstalling the theme or even going extreme and reinstalling magento? Or is it better to just wait for the patch?


That’s your call, depending on your patience and free time. Personally, when I go through a rough patch of issues, I like to start again to see if the things I’ve learned result in a smoother experience. Lord knows I must have installed Magento 2.2 about 25 times over a matter of weeks before I was comfortable enough to understand what each step in the process did and why it did it. Which then resulted in me doing M2 videos.

Sometimes, when we don’t have the “expertise” to fall back on we have to “trial and error” in the hope that we learn from our mistakes. And I’ve made soooooo many mistakes :slight_smile:

split this topic #24

A post was split to a new topic: Cannot install Magento 2.3 “your PHP version (7.3.3) does not satisfy that requirement”


Just wanted to post my results. After clean Magento installation and theme installation (actually during theme installation) I still run into “access denied” problem. Now I wonder if there is something I can do while waiting for Magento 2.3.1 patch.
Maybe there is a way to not have any restricitons about who can do what. I mean it’s just me on the server so might as well do this and reverse it later.

split this topic #27

A post was split to a new topic: How do I backup my database?