Magento2: Magento2 cannot resolve path to pub/static JS files

Created on 19 Dec 2016  路  51Comments  路  Source: magento/magento2


Preconditions


  1. Magento ver. 2.1.3
  2. PHP 7.0
  3. MySQL 5.6

All of the above running in docker containers. Files are sync'ed using docker-sync utility, but I've also tried mounting volumes directly from my local host drive and it did not help.

I've confirmed that PHP is running as www-data user and that all project files have read & write permissions on every file and directory within the project.

I have previously tried deleting all manual content and running setup:static-content:deploy. Static files were re-created, but it didn't help me to solve my problem.

Lastly, I've troubleshooted the code as far as I could and got to the point where in

vendor/magento/framework/View/Design/FileResolution/Fallback/Resolver/Simple.php file

protected function resolveFile(RuleInterface $fallbackRule, $file, array $params = [])
    {
        //->getPatternDirs return Array ( [0] => /var/www/html/lib/web )
        // given that nginx doc root path is /var/www/html
        foreach ($fallbackRule->getPatternDirs($params) as $dir) {
            $path = "{$dir}/{$file}";
            $dirRead = $this->readFactory->create($dir);
            if ($dirRead->isExist($file) && $this->checkFilePathAccess($file, $path)) {
                return $path;
            }
        }
        return false;
    }

Error details:

Unable to resolve the source file for '_requirejs/adminhtml/Magento/backend/en_US/requirejs-config.js'
#0 /var/www/html/vendor/magento/framework/App/StaticResource.php(97): Magento\Framework\View\Asset\File->getSourceFile()
#1 /var/www/html/vendor/magento/framework/App/Bootstrap.php(258): Magento\Framework\App\StaticResource->launch()
#2 /var/www/html/pub/static.php(13): Magento\Framework\App\Bootstrap->run(Object(Magento\Framework\App\StaticResource))
#3 {main}

Also, I have confirmed that these files actually exist, but Magento is unable to work out their paths correctly.

Steps to reproduce

  1. Open management page or default Luma page

Expected result

  1. All files are loaded and all Javascript on the page is working

Actual result

  1. The files below can not be loaded, thus no JS is working on the page

Clear Description Format is valid needs update bug report
Source
picture zucler
👍14

Most helpful comment

I ran into the same issue with the upgrade, and the solution is updating the nginx or apache configuration to fix the rewriting issues. The /static/ section of Nginx should be as follows to be able to get it working properly.

 location /static/ {
    if ($MAGE_MODE = "production") {
      expires max;
    }

    # Remove signature of the static files that is used to overcome the browser cache
    location ~ ^/static/version {
      rewrite ^/static/(version\d*/)?(.*)$ /static/$2 last;
    }

    location ~* \.(ico|jpg|jpeg|png|gif|svg|js|css|swf|eot|ttf|otf|woff|woff2)$ {
      add_header Cache-Control "public";
      add_header X-Frame-Options "SAMEORIGIN";
      expires +1y;

      if (!-f $request_filename) {
        rewrite ^/static/(version\d*/)?(.*)$ /static.php?resource=$2 last;
      }
    }

    location ~* \.(zip|gz|gzip|bz2|csv|xml)$ {
      add_header Cache-Control "no-store";
      add_header X-Frame-Options "SAMEORIGIN";
      expires off;

      if (!-f $request_filename) {
         rewrite ^/static/(version\d*/)?(.*)$ /static.php?resource=$2 last;
      }
    }

    if (!-f $request_filename) {
      rewrite ^/static/(version\d*/)?(.*)$ /static.php?resource=$2 last;
    }

    add_header X-Frame-Options "SAMEORIGIN";
  }
picture jmonschke on 21 Dec 2016
👍29

All 51 comments

I noticed the same issue. After installing a blank Magento 2.1.3 you are not able to use the backend because of the missing files.

swieczorek picture swieczorek on 19 Dec 2016

I have the same issue after upgrading from Magento 2.1.2 (Enterprise) to Magento 2.1.3 using a composer upgrade.

I think it's due to changes made in static files - see release notes:

  • We鈥檝e corrected a problem with _requirejs asset retrieval via static.php in static content versioning.
  • Versioning of static files (including CSS, JS, font, and image files) is now enabled by default.

I am using example nginx configuration, and have tried switching to both developer and production modes. Request reaches static.php correctly which then returns a 404 header to nginx. The referenced files exist on disk and I have verified file permissions.

I used the following workaround to disable static file signing, which has corrected the 404 for me:

INSERT INTO `core_config_data` (`scope`, `scope_id`, `path`, `value`) VALUES ('default', 0, 'dev/static/sign', '0');

You will need to clear cache after this, and also check for any entries with the same config path if you have previously modified this setting.

This isn't a very good workaround as it would break cache-busting when using Varnish or any CDNs etc, but at least assets do not 404.

careys7 picture careys7 on 20 Dec 2016
👍26

I ran into the same issue with the upgrade, and the solution is updating the nginx or apache configuration to fix the rewriting issues. The /static/ section of Nginx should be as follows to be able to get it working properly.

 location /static/ {
    if ($MAGE_MODE = "production") {
      expires max;
    }

    # Remove signature of the static files that is used to overcome the browser cache
    location ~ ^/static/version {
      rewrite ^/static/(version\d*/)?(.*)$ /static/$2 last;
    }

    location ~* \.(ico|jpg|jpeg|png|gif|svg|js|css|swf|eot|ttf|otf|woff|woff2)$ {
      add_header Cache-Control "public";
      add_header X-Frame-Options "SAMEORIGIN";
      expires +1y;

      if (!-f $request_filename) {
        rewrite ^/static/(version\d*/)?(.*)$ /static.php?resource=$2 last;
      }
    }

    location ~* \.(zip|gz|gzip|bz2|csv|xml)$ {
      add_header Cache-Control "no-store";
      add_header X-Frame-Options "SAMEORIGIN";
      expires off;

      if (!-f $request_filename) {
         rewrite ^/static/(version\d*/)?(.*)$ /static.php?resource=$2 last;
      }
    }

    if (!-f $request_filename) {
      rewrite ^/static/(version\d*/)?(.*)$ /static.php?resource=$2 last;
    }

    add_header X-Frame-Options "SAMEORIGIN";
  }
jmonschke picture jmonschke on 21 Dec 2016
👍29

Thanks @jmonschke - my nginx file was missing the fix added in #2323. Adding this works for me.

It seems that the other version regexes are redundant (or were broken prior to #2323). I think these should just be removed (see #7921).

careys7 picture careys7 on 21 Dec 2016
👍1

@zucler @careysizer @swieczorek @jmonschke Guys, can you provide us with more information about your configuration to reproduce this issue.

  • Are you all encountering this issue after update from previous version (what version?) to 2.1.3?
  • Are you all using Nginx?
  • Are you all using docker?
  • What edition of Magento do you use: CE or EE?
  • What permissions and ownership do you have for Magento webroot?
    I tested it with the following permissions: http://magento.stackexchange.com/a/95033

Firstly, I installed Magento CE 2.1.3 via composer on docker contains: 1 with nginx & php, 1 with mysql in default and developer mode and it works.
Secondly, in installed Magento CE 2.1.3 on vagrant with nginx/1.10.2, php 7.0.14, mysql 5.6 in default, developer and production modes and it works fine.
Thirdly, I installed Magento CE 2.1.2 on vagrant with nginx/1.10.2, php 7.0.14, mysql 5.6 in default& developer modes and updated via composer to Magento CE 2.1.3 and it worked.
But after I switched to production mode after upgrade from previous version to 2.1.3 I got an exception:

php bin/magento setup:static-content:deploy
Requested languages: en_US
Requested areas: frontend, adminhtml
Requested themes: Magento/blank, Magento/luma, Magento/backend
=== frontend -> Magento/blank -> en_US ===
=== frontend -> Magento/luma -> en_US ===
=== adminhtml -> Magento/backend -> en_US ===
.

  [Magento\Framework\Exception\FileSystemException]                                                                                                    
  The path "_requirejs/adminhtml/Magento/backend/en_US/requirejs-config.js:///var/www/magento/pub/static/var/www/magento/pub/static/" is not writable

Is this it?

adifucan picture adifucan on 22 Dec 2016

@adifucan That is not the issues that I was seeing at all. The issue was that the files were there and being generated, but when the browser made the request for them, the web server was unable to do anything about it.

There are new nginx.conf.sample and .htaccess.sample files in the repository that you should pay attention to when running this particular upgrade.

jmonschke picture jmonschke on 22 Dec 2016

@jmonschke Sorry for inconvenience but can you provide us with exact steps to reproduce this bug?

  • Do you encounter this issue after update from previous version (what version?) to 2.1.3?
  • Do you use Nginx?
  • Do you use docker?
  • What edition of Magento do you use: CE or EE?
  • What permissions and ownership do you have for Magento webroot?
  • What mode are you in?
  • Do you have root $MAGE_ROOT/pub; in nginx.conf.sample file?
    I'm using the latest nginx.conf.sample and .htaccess.sample files.
    Thanks!
adifucan picture adifucan on 23 Dec 2016

@adifucan I saw this when upgrading from 2.1.2 to 2.1.3.

I am using nginx and docker and EE.

I'm in developer mode, and have a special www-data user and group as ownership of the magento files.

jmonschke picture jmonschke on 23 Dec 2016

@jmonschke I have just installed Magento EE 2.1.2 on Vagrant with composer and nginx as a web server. I set permissions and ownership like here: http://devdocs.magento.com/guides/v2.1/install-gde/prereq/file-system-perms.html
I'm in developer mode.
Then I updated Magento to 2.1.3 with composer update like here: http://devdocs.magento.com/guides/v2.0/comp-mgr/cli/cli-upgrade.html
And Magento (backend/frontend works) fine.

So I guess probably it's the issue with docker?

But I have one more question: do you set the Magento root directory to /pub or not?
I tested it WITHOUT pub directory root. So may be that's the reason why I cannot reproduce it?

Thanks!

adifucan picture adifucan on 26 Dec 2016

I have this issue too in developer mode and Magento 2.1.3. For me is related to static files versioning that is defaulted to "on" in Magento 2.1.3. If I change it back to off (from database since admin interface is not working anymore) then it goes well.

giacmir picture giacmir on 27 Dec 2016

@adifucan to answer you questions:

Do you encounter this issue after update from previous version (what version?) to 2.1.3?
No, this is my first time with Magento, I have just installed a clean version.

Do you use Nginx?
Yes, I do

Do you use docker?
Yes, I followed this guide: http://andykdocs.de/development/Docker/Dockerize-Magento-2-on-Mac-OS

What edition of Magento do you use: CE or EE?
Community Edition

What permissions and ownership do you have for Magento webroot?
www-data, all files user and group are set to www-data, permissions are 775

What mode are you in?
Development mode

Do you have root $MAGE_ROOT/pub; in nginx.conf.sample file?
Yes

I haven't tried @jmonschke workaround yet, but I'm definitely running the latest nginx config, so @careysizer case doesn't apply to my setup.

Thanks!

P.S. I traced my problem to the fact that it gets to static.php script that is then failing to work out a correct path. So, I don't think it is related to permissions. I've also tried changing all files permissions within the container to 777 and it didn't help. Files do exist on the disk though.

zucler picture zucler on 27 Dec 2016

Hi, I have a similar problem but I see the file are in _pub/static/_requirejs/adminhtml/Magento/backend/es_CL/_ because i change the default language using setup:install --language=es_CL Any idea?

slimzc picture slimzc on 28 Dec 2016

@slimzc - Its all the same problem, regardless of what language you have chosen (from what I understand).

spyrule picture spyrule on 29 Dec 2016

I encounterd this problem after installing a custum language packege.
I had a fresh 2.1.3 production installation from tar ball using Apache and everything was working fine. After running bin/magento setup:di:compile require js was not able to find the files any more.
My guess is that the fresh installed version containes some uncompiled changes and thats why you can't reproduce it in a fresh installation. Can someone confirm this?

Additionally the database fix did not work for me.

WaeCo picture WaeCo on 29 Dec 2016

Can confirm the same problem. I installed a fresh version 2.1.3 with sample data and run in to the same error with the missed links/files. Can't use the backend.

AgenturSchroeder picture AgenturSchroeder on 3 Feb 2017

I can confirm that adding the rewrite Nginx configuration fixes the issue. Thanks @careys7 and @jmonschke

jalogut picture jalogut on 16 Feb 2017

error

How to remove version from link .

hrushikesh07 picture hrushikesh07 on 11 Apr 2017

You can disable option in your admin
Stores>Configuration>Advanced>Developer>Sign Static Files (dev_static_sign)

Or simply insert this row in your _core_config_data_ table
insert core_config_data (config_id, scope, scope_id, path, value) values (null, 'default', 0, 'dev/static/sign', 0);

slimzc picture slimzc on 11 Apr 2017
👎4 👍2

You can disable option in your admin

Have you even tried saving a config value in admin while not having JS operational? =D
The SQL workaround was already mentioned above. Please read the whole thread first (before rushing to comment). Besides, it must be noted that saving that option simply disables the feature and doesn't fix it.

korostii picture korostii on 12 Apr 2017

I am using Fedora 25 , having
Apache/2.4.25 (Fedora)
PHP Version 7.0.18
MySql 5.7.18

I have just installed magneto 2.1.6 , after successfull setup run, its getting css and js files not found issue and they are loading from pub/static//version1494143163/frontend/Magento/luma/en_US/css/styles-m.css
version1494143163 is not even existed.
Beside this the admin url is also not accessible .

Can anyone can help me

nafisakanwal picture nafisakanwal on 8 May 2017
😕1

I got the same issue, which like nafisakanwal

mfang0126 picture mfang0126 on 13 May 2017

It looks to me like "sign static files" is inserting "versionNNNNNNNNN" into the URLs, but setup:static-content-deploy is not placing the content in that path.

dnadle picture dnadle on 13 May 2017

That is as expected/not the problem: the file ".htaccess" in pub/static contains this rewrite-rule:

    # Remove signature of the static files that is used to overcome the browser cache
    RewriteRule ^version.+?/(.+)$ $1 [L]

I.e. the version?????-part is taken out of the url before hitting the filesystem.

However, is the url reachable if you remove the version????-part?
I have this problem, too, but it seems only with module Magento_ConfigurableProduct
Both "http://myserver/shop/static/version1496826764/adminhtml/Magento/backend/de_DE/Magento_ConfigurableProduct/js/components/custom-options-warning.js" and "http://myserver/shop/static/adminhtml/Magento/backend/de_DE/Magento_ConfigurableProduct/js/components/custom-options-warning.js" return:
Unable to resolve the source file for 'adminhtml/Magento/backend/de_DE/Magento_ConfigurableProduct/js/components/custom-options-warning.js'

dev@www:~/magento$ ls -l vendor/magento/module-configurable-product/view/base/adminhtml/web/js/components/
total 48
-rw-rw-rw- 1 dev dev  9463 Mar 28 15:26 associated-product-insert-listing.js
-rw-rw-rw- 1 dev dev  1777 Mar 28 15:26 container-configurable-handler.js
-rw-rw-rw- 1 dev dev  1970 Mar 28 15:26 custom-options-price-type.js
-rw-rw-rw- 1 dev dev   662 Mar 28 15:26 custom-options-warning.js
-rw-rw-rw- 1 dev dev 15920 Mar 28 15:26 dynamic-rows-configurable.js
-rw-rw-rw- 1 dev dev  2325 Mar 28 15:26 file-uploader.js
-rw-rw-rw- 1 dev dev   883 Mar 28 15:26 modal-configurable.js
dev@www:~/magento$ curl -I http://myserver/shop/static/adminhtml/Magento/backend/de_DE/Magento_Catalog/catalog/product.js
HTTP/1.1 200 OK
Date: Wed, 07 Jun 2017 10:06:00 GMT
Server: Apache/2.4.10 (Debian)
Last-Modified: Tue, 28 Mar 2017 13:25:54 GMT
ETag: "8db-54bca66385c80"
Accept-Ranges: bytes
Content-Length: 2267
Vary: Accept-Encoding
Content-Type: application/javascript

dev@www:~/magento$ curl -I http://myserver/shop/static/adminhtml/Magento/backend/de_DE/Magento_ConfigurableProduct/js/components/custom-options-warning.js
HTTP/1.1 404 Not Found
Date: Wed, 07 Jun 2017 10:06:16 GMT
Server: Apache/2.4.10 (Debian)
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Content-Type: text/plain;charset=UTF-8

dev@www:~/magento$ curl http://myserver/shop/static/adminhtml/Magento/backend/de_DE/Magento_ConfigurableProduct/js/components/custom-options-warning.js
Unable to resolve the source file for 'adminhtml/Magento/backend/de_DE/Magento_ConfigurableProduct/js/components/custom-options-warning.js'
#0 /home/dev/magento/vendor/magento/framework/App/StaticResource.php(97): Magento\Framework\View\Asset\File->getSourceFile()
#1 /home/dev/magento/vendor/magento/framework/App/Bootstrap.php(258): Magento\Framework\App\StaticResource->launch()
#2 /home/dev/magento/pub/static.php(13): Magento\Framework\App\Bootstrap->run(Object(Magento\Framework\App\StaticResource))
#3 {main}

This is a Magento-CE 2.1.6

timri picture timri on 7 Jun 2017

Ok, my problem is solved now (but has nothing to do with this bug):
Someone accidentally moved the folder vendor/magento/module-configurable-product/view/adminhtml inside vendor/magento/module-configurable-product/view/base

timri picture timri on 9 Jun 2017

# now i know why can't linking style ,but i don't know why this?
because install path no version1499055289 folder ,and i add it style work
qq 20170703141604
qq 20170703141841
qq 20170703142510
but i don't know why it can't add version1499055289 folder itself in During the installation process

mengbo123456 picture mengbo123456 on 3 Jul 2017

Hey everyone, I think I got a fix for you:

I had this same issue on a new magento install. There are two issues here at play: Malformed apache configuration and non-deployed static content (at least for me). It is not mentioned at http://devdocs.magento.com/guides/v2.1/install-gde/install/web/install-web_6-install.html, but you need to run the command bin/magento setup:static-content:deploy for pub/static/ to be populated with the static content. (Huge thanks to Anil Suthar (Stack Overflow))

I wouldn't recommend changing permissions to 777, what I did was do it as single user setup and set permissions to web server user, default is www-data:chown -R www-data:www-data /. (Note: this StackOverflow post has some good points about permissions)

Lastly, what's up with the folder versionXXXXXXXXXX? Well, if you look at .htaccess in pub/static/ you'll see two Rewrite Rules:

RewriteRule ^version.+?/(.+)$ $1 [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l

RewriteRule .* ../static.php?resource=$0 [L]

(The second one triggers if the requested resource is not found)

The first rule removes the version folder in the request and serves instead frontend/ or adminhtml/ the resource asks for.

Check what apache2.conf says in /etc/apache2/ (if Ubuntu), it's possible that /var/www/ directory has AllowOverride None set. It should be AllowOverride All, so that .htaccess files can override directives.

All of that fixed it for me, I hope this helps anyone else!

........
Sigh, Post Factum I've found out that this is problem is mentioned in the verify installation page. Here's the link that basically mimics what I wrote here: http://devdocs.magento.com/guides/v2.1/install-gde/trouble/tshoot_no-styles.html

ignat980 picture ignat980 on 17 Aug 2017
👍3 ❤1

I must have erased the .htaccess file in /pub/static by accident...I've been looking for the answer for 3 hours!

So if you're missing your theme on your admin and your store... check for a versionXXXXXXXXXX in the firebug console. if so recreate the .htaccess file with the above 4 lines in it.

Thank you so much!

ozziel picture ozziel on 7 Oct 2017
🎉2

Hi @zucler
Could you please let us know if the issue is still actual? Thank you

magento-engcom-team picture magento-engcom-team on 24 Nov 2017

I can see this issue is still actual from errors reported on the google search consol under crawl errors. Have a look at the below:
google webmaster

wd7080 picture wd7080 on 30 Nov 2017

Hi @wd7080
Your issue don't related with issue by first reporter.
If you have an issue, you should create new ticket and describe steps to reproduce.

magento-engcom-team picture magento-engcom-team on 7 Dec 2017

@zucler, we are closing this issue due to inactivity. If you'd like to update it, please reopen the issue.

magento-engcom-team picture magento-engcom-team on 7 Dec 2017

just run a2enmod rewrite (on apache server). It's working for me

bdt195 picture bdt195 on 15 Mar 2018

I've exactly the same issue, I've tried the suggested by @ignat980 without success. Also de @careys7 suggested solution didn't work for me neither.

bruno-serfe picture bruno-serfe on 6 Apr 2018

This is work for me.
I Just back .htaccess file to the folder pub/static/

Thanks ozziel

### ozziel commented on 7 Oct 2017

I must have erased the .htaccess file in /pub/static by accident...I've been looking for the answer for 3 hours! So if you're missing your theme on your admin and your store... check for a versionXXXXXXXXXX in the firebug console. if so recreate the .htaccess file with the above 4 lines in it. Thank you so much!

mehreeizad1 picture mehreeizad1 on 17 May 2018

I have the same issue after upgrading from Magento 2.1.2 (Enterprise) to Magento 2.1.3 using a composer upgrade.

I think it's due to changes made in static files - see release notes:

  • We鈥檝e corrected a problem with _requirejs asset retrieval via static.php in static content versioning.
  • Versioning of static files (including CSS, JS, font, and image files) is now enabled by default.

I am using example nginx configuration, and have tried switching to both developer and production modes. Request reaches static.php correctly which then returns a 404 header to nginx. The referenced files exist on disk and I have verified file permissions.

I used the following workaround to disable static file signing, which has corrected the 404 for me:

INSERT INTO `core_config_data` (`scope`, `scope_id`, `path`, `value`) VALUES ('default', 0, 'dev/static/sign', '0');

You will need to clear cache after this, and also check for any entries with the same config path if you have previously modified this setting.

This isn't a very good workaround as it would break cache-busting when using Varnish or any CDNs etc, but at least assets do not 404.

Thanks @careys7 : This solution worked.

JORDYSCHEMPARATHY picture JORDYSCHEMPARATHY on 2 Apr 2019
👍2

I noted solution here:
https://mrvts.wordpress.com/2020/01/03/static-content-is-not-loading-when-enable-static-sign-version-404-for-js-css-and-media/

vtransy picture vtransy on 3 Jan 2020

I have the same issue after upgrading from Magento 2.1.2 (Enterprise) to Magento 2.1.3 using a composer upgrade.
I think it's due to changes made in static files - see release notes:

  • We鈥檝e corrected a problem with _requirejs asset retrieval via static.php in static content versioning.
  • Versioning of static files (including CSS, JS, font, and image files) is now enabled by default.

I am using example nginx configuration, and have tried switching to both developer and production modes. Request reaches static.php correctly which then returns a 404 header to nginx. The referenced files exist on disk and I have verified file permissions.
I used the following workaround to disable static file signing, which has corrected the 404 for me:

INSERT INTO `core_config_data` (`scope`, `scope_id`, `path`, `value`) VALUES ('default', 0, 'dev/static/sign', '0');

You will need to clear cache after this, and also check for any entries with the same config path if you have previously modified this setting.
This isn't a very good workaround as it would break cache-busting when using Varnish or any CDNs etc, but at least assets do not 404.

Thanks @careys7 : This solution worked.

Thanks @careys7 : This solution worked for me Also

masmaleki picture masmaleki on 24 Jan 2020

You can disable option in your admin
Stores>Configuration>Advanced>Developer>Sign Static Files (dev_static_sign)

Or simply insert this row in your _core_config_data_ table
insert core_config_data (config_id, scope, scope_id, path, value) values (null, 'default', 0, 'dev/static/sign', 0);

Thanks, Worked for me on Magento 2.3.3 and Wamp Server On Wndows

masmaleki picture masmaleki on 24 Jan 2020

I have the same issue after upgrading from Magento 2.1.2 (Enterprise) to Magento 2.1.3 using a composer upgrade.

I think it's due to changes made in static files - see release notes:

  • We鈥檝e corrected a problem with _requirejs asset retrieval via static.php in static content versioning.
  • Versioning of static files (including CSS, JS, font, and image files) is now enabled by default.

I am using example nginx configuration, and have tried switching to both developer and production modes. Request reaches static.php correctly which then returns a 404 header to nginx. The referenced files exist on disk and I have verified file permissions.

I used the following workaround to disable static file signing, which has corrected the 404 for me:

INSERT INTO `core_config_data` (`scope`, `scope_id`, `path`, `value`) VALUES ('default', 0, 'dev/static/sign', '0');

You will need to clear cache after this, and also check for any entries with the same config path if you have previously modified this setting.

This isn't a very good workaround as it would break cache-busting when using Varnish or any CDNs etc, but at least assets do not 404.

Thanks, Worked for me on Magento 2.3.3 and Wamp Server On Wndows

masmaleki picture masmaleki on 24 Jan 2020

This is still an issue on Magento 2.3.4.

This happens with a brand new, fresh M2 install.

I'm using:

  • centos-release-7-7.1908.0.el7.centos.x86_64
  • httpd 2.4.41
  • php 7.2.27 (fpm-fcgi)

Permissions all correct, rewrites enabled etc.

Disabling static content signing is not a real solution because it will affect caching etc.

I can't believe this issue has been closed.

@magento-engcom-team Please re-open this issue.

diamondavocado picture diamondavocado on 9 Mar 2020

Agreed, having it on 2.3.4 also...

jackrevate picture jackrevate on 29 Apr 2020

He tratado todas las soluciones aportadas por varios sitios sin soluci贸n. Finalmente el problema estaba en los archivos de sesi贸n.
Por un error en mi servidor plesk modifique temporalmente el directorio de almacenamiento de sesi贸n en env.php al directorio var/sessions en mi raid de magento.
Modifique los permisos en mi servidor para el almacenamiento de sesion y restarure env.php para almacenar nuevamente las sesiones en el directorio de mi servidor e inmediatamente se corrigio el problema. Espero le sirva a alguien o de luz a algun problema similar.

Javiercc78 picture Javiercc78 on 8 May 2020

I'm sorry but that's pathetic... M2 v2.3.5

dndeus picture dndeus on 6 Jun 2020

Still happening on 2.3.5 with nginx.conf.sample

psolovyov picture psolovyov on 15 Jun 2020
👍1

Seeing the same on 2.4.0 Open Source/CE - site running fine for weeks following initial installation, no problems till the day I tried static deploy / di compile etc. After first attempt the admin went dead, google TFA disappeared during login, etc. Require.js failing to load at the "version" URL despite Apache setup allowing overrides, no missing htaccess file, permissions set fine, ownership fine, etc etc etc... I also tried changing app/etc/di.xml MaterializationStrategy to "copy" and back to "Symlink" with no difference either way.

BuysTooMuch picture BuysTooMuch on 12 Oct 2020

Saem problem version 2.4.0

diegoot-dev picture diegoot-dev on 14 Oct 2020

Having the same issue on a fresh Magento 2.4.1 installation. In developer mode I get 403 access denied on some .js and .css files. Interestingly enough those files are just symlinked. When I switch to production mode everything is fine (theres some bugs in the initial files though which wont let you compile - some commas at the wrong places in the code). Anyone ever solved this?

s1mplex1337 picture s1mplex1337 on 19 Oct 2020

having same problem after upgrading to magento 2.4.1

angelflo picture angelflo on 19 Oct 2020
👍1

For some reason, and I don't really know why exactly, but check your apache settings and disable "Restrict the ability to follow symbolic links". I dont know why this suddenly seems to be a problem on Magento 2.4+ (I'm running other Magento 2.3.x installations on the same server without any issues). But disabling this worked out for me.

You can also try this, to actually get rid of Magento using symlinks: https://community.magento.com/t5/Can-Magento-do/How-to-use-Magento-2-with-no-symlinks-anywhere/td-p/48402

s1mplex1337 picture s1mplex1337 on 19 Oct 2020

I use nginx ... does someone have a fix for this ?

angelflo picture angelflo on 19 Oct 2020

I use nginx ... does someone have a fix for this ?

I'm not sure about that, I used nginx as a proxy with apache and not pure nginx. I would recommend you to do so aswell. However you might try to make Magento not use symlinks with this:

1) Open app/etc/di.xml
2) Replace all Magento\Framework\App\View\Asset\MaterializationStrategy\Symlink occurrences with Magento\Framework\App\View\Asset\MaterializationStrategy\Copy

Found this here: https://community.magento.com/t5/Can-Magento-do/How-to-use-Magento-2-with-no-symlinks-anywhere/td-p/48402

It might help if you have the symlink issue.

s1mplex1337 picture s1mplex1337 on 19 Oct 2020
Was this page helpful?
0 / 5 - 0 ratings

Related issues

comunidademagento picture comunidademagento  路  3Comments
kandrejevs picture kandrejevs  路  3Comments
phirunson picture phirunson  路  3Comments
andreaskoch picture andreaskoch  路  3Comments
salelsol picture salelsol  路  3Comments