[SOLVED] Moved NEOS installation -> _Resources paths

Using Neos & Flow
1

I moved a NEOS-Installation to another directory.

Under _Resources there are absolute symlinks to Data/…

What is the best way to fix a NEOS instance after moving it in the filesystem?

Thanks.

2

./flow resource:publish
should fix it.

3

Thank, that worked so far.
The symlinks are fixed, but the Webserver complains that I have no permission to access the symlinked files… how do I fix the permissions?

4

Not sure what to answer, chmod probably, maybe chown but which permissions you need depends on your server and setup.

5

Thanks, makes sense that you can’t answer this, for it is a server- not a NEOS-thing…
Something is screwed with the path’s and/or permissions on the server.

If it’s something that could be useful to know in NEOS-context, I’ll report this here

6

The problem is, in the SSH shell I work in a chrooted environment.
Because of that, if I do “./flow resource:publish”, it will generate wrong symlinks, assuming the root in the shell to be the absolute root.
As long I stay in the chrooted shell, the links work, but in Apache-Context, they will lead nowhere…

So how do I tell flow what’s the real root path?

7

So here my analysis of the problem:

If I work in a chrooted SSH-shell, and do ./flow resource:publish, the generated symlinks are wrong. Flow uses the root of the chrooted environment to generate absolute paths.

The webserver can’t find the symlinked file, because of the “absolute” path, that is only absolute in the chrooted environment.

My fix to this:

  • Export the site “./flow site:export --package-key=XXX.YYY”
  • Import the site again using the /setup in the Browser. The symlinks are generated correctly, because the webserver knows the absolute path of the web-root (and the flow-root).

The CLI has no chance to know the correct absolute path, because it runs in a chrooted environment.

Is there a way to advise flow to generate relative resource-symlinks instead of absolute ones? Or any other approach to make flow work in a chrooted environment?

Seems to be the bug reported here: https://forge.typo3.org/issues/54344
and here: https://forge.typo3.org/issues/33719

8

Finally, even clearing all caches using “./flow flow:cache:flush” and/or manually delete all Data/Temporary files and re-importing the site package (after removing it) did not solve the problem completely. Some thumbnail-files for images in the backend’s inspector did not re-generate and could not be found… could not fix this in an existing setup.

So finally, what I did is:

  • Export Site
  • Remove everything (including DB tables)
  • Setup NEOS from scratch
  • Upload Site package and Configuration
  • Setup NEOS, import my site package.

So my conclusion is:

  • never ever try to move a NEOS setup from one directory to another
  • don’t use “./flow resource:publish” in a chrooted environment. It will generate corrupt symlinks.
9

UPDATE:
Just found this: https://github.com/neos/flow-development-collection/pull/187/files
Workaround until NEOS 3.0: https://github.com/mittwald/flow-symlink-publishing

From NEOS 3.X, add these lines to Settings.yaml to enable relative symlinks:

Neos:
  Flow:
    resource:
      targets:
        localWebDirectoryPersistentResourcesTarget:
          target: 'Neos\Flow\ResourceManagement\Target\FileSystemSymlinkTarget'
          targetOptions:
            relativeSymlinks: true
        localWebDirectoryStaticResourcesTarget:
          target: 'Neos\Flow\ResourceManagement\Target\FileSystemSymlinkTarget'
          targetOptions:
            relativeSymlinks: true
10

Finally, here is the configuration for the current NEOS 2.3 LTS (>= FLOW 3.3), that makes ‘./flow resource:publish’ create relative symlinks:

TYPO3:
  Flow:
    resource:
      targets:
        localWebDirectoryPersistentResourcesTarget:
          target: 'TYPO3\Flow\Resource\Target\FileSystemSymlinkTarget'
          targetOptions:
            relativeSymlinks: true
        localWebDirectoryStaticResourcesTarget:
          target: 'TYPO3\Flow\Resource\Target\FileSystemSymlinkTarget'
          targetOptions:
            relativeSymlinks: true

With this setup, you don’t need the mittwald/flow-symlink-publishing package. You just need a NEOS with flow >=3.3

(See https://github.com/mittwald/flow-symlink-publishing)

4 Likes
11

Right! Was about to suggest that for chrooted env. Good that you found it :slight_smile:

12

Hey @thismaechler,

thanks for this detailed writeup, I am sure this will help other community members who encounter a similar issue :heart:

All the best,
Sebastian