Managing Media "Readable volumes not available" Error Message

I tried searching all over for an answer, but am at a loss. I believe this is related to file permissions, but do not see anywhere in the MODX configuration files (or elsewhere) any reference to the path/folder that the file browser is trying to access. All the folders that I think are the ones that are used for file storage look to have 755 file permissions, which I would think are fine.

When my client is trying to link to a file, she gets this error. Happens for any function that uses the file browser.

I am running MODX 3.0.3 and here are my other plugin versions:

Any help would be appreciated. Thank you.

Does it work when you try to select the file as the Administrator?

Maybe the user is lacking MODX permissions.
I believe what’s shown in the file browser is a MODX media source. Maybe the user lacks permission to list/view this media source.

Could be, but I am logging into the MODX admin with my client’s account and can view, upload, and even delete files from the assets and file system folders. Only when she is using the FRED CMS editor on the webpage does this happen.
MODX2

She never had an issue before we upgraded MODX and FRED recently. I guess the one thing we forgot to test after the upgrade was this feature! Most likely was broken since the upgrade.

Just confused as to where this may be configured. Everything would have been a ‘vanilla’ default upgrade and no special folders or configurations to the main MODX and FRED applications or the website file structure.

Grrr…

Why not simply test it? If it works for a user with sudo permissions and not for another user, then you know it’s a MODX permission issue.

Also, when you can view something in the manager, it doesn’t necessarily mean that it works from the frontend as well, as this is another context (“web” instead of “mgr”).


You could also open the developer tools in the browser and go to the “Network” tab.
When you click the “Browse” button in the frontend, it should make an AJAX-request to assets/components/fred/web/endpoints/elfinder.php.
Maybe there is something in the response that gives more insight.

BlockquoteWhy not simply test it? If it works for a user with sudo permissions and not for another user, then you know it’s a MODX permission issue.

This is what is confusing. She is the site admin. Has FULL access to everything in the Administrator ACL (which has all options selected). She is SUDO from what I can see. And she cannot use the browse function in the RTE. Gets that error message.

user

Which makes me belive it is a configuration issue? Like that elfinder application does not know of, or is going to, the correct path to where all the files should be stored.

I searched for a long time trying to figure out how to see where its path is being referenced or set. I don’t see anything logical in the MODX system settings that is related to this.

And what I see in, what I think, is the elfinder configuration file is this:

// Documentation for connector options:
// https://github.com/Studio-42/elFinder/wiki/Connector-configuration-options
$opts = array(
	// 'debug' => true,
	'roots' => array(
		// Items volume
		array(
			'driver'        => 'LocalFileSystem',           // driver for accessing file system (REQUIRED)
			'path'          => '../files/',                 // path to files (REQUIRED)
			'URL'           => dirname($_SERVER['PHP_SELF']) . '/../files/', // URL to files (REQUIRED)
			'trashHash'     => 't1_Lw',                     // elFinder's hash of trash folder
			'winHashFix'    => DIRECTORY_SEPARATOR !== '/', // to make hash same to Linux one on windows too
			'uploadDeny'    => array('all'),                // All Mimetypes not allowed to upload
			'uploadAllow'   => array('image/x-ms-bmp', 'image/gif', 'image/jpeg', 'image/png', 'image/x-icon', 'text/plain'), // Mimetype `image` and `text/plain` allowed to upload
			'uploadOrder'   => array('deny', 'allow'),      // allowed Mimetype `image` and `text/plain` only
			'accessControl' => 'access'                     // disable and hide dot starting files (OPTIONAL)
		),
		// Trash volume
		array(
			'id'            => '1',
			'driver'        => 'Trash',
			'path'          => '../files/.trash/',
			'tmbURL'        => dirname($_SERVER['PHP_SELF']) . '/../files/.trash/.tmb/',
			'winHashFix'    => DIRECTORY_SEPARATOR !== '/', // to make hash same to Linux one on windows too
			'uploadDeny'    => array('all'),                // Recomend the same settings as the original volume that uses the trash
			'uploadAllow'   => array('image/x-ms-bmp', 'image/gif', 'image/jpeg', 'image/png', 'image/x-icon', 'text/plain'), // Same as above
			'uploadOrder'   => array('deny', 'allow'),      // Same as above
			'accessControl' => 'access',                    // Same as above
		)
	)
);

That comes from the file:

public_html/assets/components/fred/web/vendor/elfinder/php/connector.minimal.php-dist

which is the only config file I find that has anything to do with elfinder. Which I don’t think is used because it has .php-dist as the file extension and not simply .php??

And if I do not know the actual starting path that elfinder is trying to work from, then ../files/ could be anywhere!

From what I can see in the code that gets executed when elFinder opens (the AJAX-request to assets/components/fred/web/endpoints/elfinder.php I mentioned above), the code loops through all the media-sources of the page and checks if they have a property with the name “fred” that has a value of “true”. The base-paths of the matching media-sources are then used as the roots for elFinder.

(When I set the “fred” property of the media-source to “false” on my test installation, I get the same error message you posted above → “Invalid backend configuration. Readable volumes not available.”)

UGGH! So frustrating. Just to pacify my recollection of the past, I looked at my clients files and sure enough, in the instructions I created a couple of years ago, I did validate that she could use this functionality just fine. Screen caps and all to prove it! Even the filesystem folder defaulted to the root view, which I assume is the basic, default way it is (at least was) configured.

I don’t know what changed with this fresh installation. Everything else has been working perfectly. This is what is in the main filesystem media source. It should just default to the web root when this el(not!)finder fires up. Even has the permissions of admin and super user. Should not have any issues with permissions, IMO. (screen cap shows visibility as private; tried that as an option but still didn’t work when set to public.)


I even created two other sources, each with the same access permissions. Each going to a different folder in the public_root of the website. Each folder is set for 0755 permissions. I can upload files directly to them from the cPanel file manager. I even named one of the media sources “fred,” purely out of frustration! (also tried the URL values with a leading slash to place the reference at the root, /docs/ and /files/).

I tried logging in as two other users in different browsers (to ensure fresh sessions, etc…). One was a sudo account and the other just a general admin role with full rights. Nada. Same blocking.

Even when I look at Network in dev tools I see nothing unusual. All 200 status and I see the ajax call. All looks normal.

Sometimes it can be helpful to (temporarily) log some information in the code to figure out what’s going on.
You could for example (temporarily) add this line

$this->modx->log(\modX::LOG_LEVEL_ERROR,'elFinder roots: ' . print_r($roots, true));

to the code here

This should log the roots (from the media-sources) to the MODX error log.

Does a root exist (or does an empty array get logged)?
If there is a root, then the problem occurs probably somewhere else.

1 Like

@halftrainedharry I really do appreciate all your time in replying. I had a couple of things I was going to try today after a night’s rest and clearing my head! I will try your suggestion, too! Finger’s crossed…

@halftrainedharry Turns out I had to update the FRED addon to the latest version. Now, if I was thinking straight, I should have read through the release notes for the versions. While it did not mention anything about elFinder for the latest release (2.1.3-pl), I looked at the version before that (2.1.2-pl) and it listed:

  • Update elFinder endpoint to use latest revisions from barryvdh repository
  • Restore thumbnails for images in the file manager

The thing that tipped me off about updating was that I could not find the file at:

/core/components/fred/src/Endpoint/ElFinder.php

I only saw one ElFinder.php file and it was not at that location nor did it have the same code as what was shown above. Had no way to even insert any tracking code! Obviously, the newer releases introduced a different file structure.

Hoping if anyone else may have an issue like this that this thread will help get it resolved.

Again, thanks for all your suggestions and time spent helping me!

This topic was automatically closed 2 days after discussion ended and a solution was marked. New replies are no longer allowed. You can open a new topic by clicking the link icon below the original post or solution and selecting “+ New Topic”.