Bug #103150
closed
After Update to 11.5.35 -> Call to a member function getStorage() on bool | Error thrown in file ...FileLinkHandler.php
0%
Description
After the update from 11.5.34 to 11.5.35 we get the following error when trying to create a textlink to a file in the Text & Media element:
Core: Exception handler (WEB): Uncaught TYPO3 Exception:
Call to a member function getStorage() on bool | Error thrown in file /var/www/public/typo3/sysext/recordlist/Classes/LinkHandler/FileLinkHandler.php in line 126
The error occurs with backend editors, not with the admin account.
Files
Updated by Benjamin Robinson 3 months ago
I can confirm the error. I have exactly the same problem with an 11.5.35. However, I have a second 11.5.35 TYPO3 where the problem does not occur. Unfortunately, I have not yet found the decisive difference between the two systems.
Updated by Andreas Kienast 3 months ago
- Is duplicate of Bug #103116: Oops, an error occurred! Call to a member function getStorage() on bool added
Updated by Andreas Kienast 3 months ago
- Status changed from New to Closed
Thank you for your report. This issue was reported previously with https://forge.typo3.org/issues/103116 and handled as such. Therefore, I'll close this ticket as a duplicate.
Kind regards
Andreas
Updated by Benjamin Franzke 3 months ago
ยท Edited
can you confirm that the installation where the issue exists does not have 1:/user_upload mounted for editors, while the installation where the error does not happen does provides access to 1:/user_upload for editors?
Updated by Benjamin Robinson 3 months ago
Benjamin Franzke wrote in #note-4:
can you confirm that the installation where the issue exists does not have
1:/user_uploadmounted for editors, while the installation where the error does not happen does provides access to1:/user_uploadfor editors?
No, in both installations editors don't have access to user_upload. But the installation with the issue has a user-TSconfig
options.defaultUploadFolder = 1:media/
The problem could have been that the editors don't have access to this default folder. This is now solved with the patch https://forge.typo3.org/projects/typo3cms-core/repository/1749/revisions/de0f48a7099fb320c50fd4635e11c1e4015690d9
Updated by Benjamin Franzke 3 months ago
Thanks for the verification.
One last question to fully understand your case: I assume the editors do not have access to the configured folder 1:/media, right?
In that case the InsufficientFolderAccessPermissionsException would be triggered but not catched in https://github.com/TYPO3/typo3/blob/11.5/typo3/sysext/core/Classes/Authentication/BackendUserAuthentication.php#L1684-L1690 and thus no upload folder would be found (the alternatives that are resolved when the folder is missing are skipped in that case).
That explains how getSelectedFolder ended up returning false.
(Note: The fix you already verified is fine and sufficient and will soon be released, I just think we got a secondary issue here regarding correct behaviour here: inhomogeneous handling where defaultUploadFolder does not exist vs no permission)
Updated by Benjamin Robinson 3 months ago
Benjamin Franzke wrote in #note-6:
One last question to fully understand your case: I assume the editors do not have access to the configured folder
1:/media, right?
Yes, that's exactly how it is, the editors do not have access to the configured folder 1:/media
I didn't want the editors to upload files to user_upload in an unsorted and careless manner, but to put a little more effort into the directory structure. I overlooked the fact that they do not have access to 1:/media, but only to their own individual subdirectory.