OPCache needs to be disabled - Is that forever?
Some remarks:
this way you block (and terminate) the integration of
grommunio-officewhich does need to inject to files to allow a seamless interaction.in the next paragraph you redirect caldav and carddav away from
grommunio-davtogrommunio-files, breaking the integration with some DAV clients that want to access calendar/contacts.the failings of opcache are unfortunate, however APCu is a good replacement and is confirmed and certified to work with grommunio and also grommunio-files.
for nodeinfo and webfinger we have replaced these to be "well-known", ignoring them.
@mwilliams Thanks for your comments on this. There seems very little discussion/input from the community and development team regarding Grommunio Files (GF) in this forum - in fact most of the posts here concern the core Grommunio product (mail). After many years in the IT industry I have developed a general dislike for applications giving warnings/errors so started looking at what files were causing the errors being reported in the GF Admin console.
If the changes I have made/suggested to reduce the warnings/errors in the GF Admin Console should not be made, then what should we be doing to remove the entries in the console. These warnings/errors have been posted a few times by contributors on this forum, but to date I have not seen any direct input from the development team as to what we should be doing to resolve them. As an analogy, if I have a warning light appear on my car dashboard I need to find out what is causing it and fix it, not just drive around with the light on. The same goes for software, if it generates a warning/error I want to fix it before some big goes wrong (potential loss of data).
Some other points.
Does the APCu product need any configuration. OPCache has a large config file to control how it works, but nothing has been said about APCu. It is good to know that it is included in the latest build ISO's for the appliance, but does that also go for those who use the other versions of Grommunio (I can't recall if that was mentioned in @WalterH article or not). If there are tweaks that can or should be made, where can we find the information, to get the best performance for the product.
@mwilliams for nodeinfo and webfinger we have replaced these to be "well-known", ignoring them
If these have been replaced, why does the console still generate an error/warning. It makes us (the user) think there is something wrong when there probably isn't.
As a user of the Community version, I expect to get some errors/warnings from time to time, but some guidance from the development team would be useful. Clearly, in GF the errors are not critical as it works OK without making changes, its just I have spent many years trying to get rid of these types of messages so it has become a habit to try. I know there are probably far more important issues for the developers to work on as this is only an issue for those of us who dislike seeing errors.
Finally, I really do appreciate the hard work that the 'Grommunio Team' having been doing on the whole product over the nearly 2 years I have been using the product.
You might want to check out grommunio-files-26.0.12.
For APCu: While there are possibilities to enrich APCu (see also https://www.php.net/manual/en/apcu.configuration.php), this is not really required for default setups.
Finally, thanks for the kind words. The best appreciation for open source software is the support through customers. So if it is of any value for you as it seems, feel free to consider the purchase of a subscription and get all the extra benefits from it.
- Edited
I have restored the previous status and installed v26.0.12 via today's update. The status is now as follows:
From @crpb we know, that we cannot follow the recommendation to modify the maybe relevant .htaccess at this point, but that this should be adapted in nginx. However, where and how is now the question.
My VM v28.0.3 could be my goal 
When the check is running, you get a prompt, you should enter valid credentials and you will see that all your checks are green. You need to authenticate because as mentioned before, CalDAV and CardDAV are not provided by files but by grommunio-dav instead.
I confirm
- Edited
mwilliams
I also say thank you for all the amazing work you all do here.
You have marked this post as solved. But my initial question is not answered.
APCu is responsible for the user data that would otherwise be stored on the slower disk.
OPCache serves as a fast cache for the PHP scripts. That is what I need.
Currently we can not use OPCache together with Grommunio, and that is a problem.
And my question was:
Is there anything we can expect (and that the Grommunio team can do) that this may change?
If I know in the right way, since v2023.11.3 from Feb. 2024 php8-APCu is included per default in all appliances.
- Edited
mwilliams Thanks for this. When. I first started playing with Grommunio Files (GF) I kept getting that prompt and could not see why it was asking for credentials again (and I think it used to prompt multiple times) so just cancelled past it. Hadn't seen any comments in the forum to say you must validate again for Grommunio-Dav. Anyway have just tested and get:-
](https://)
Exactly the screen I like to see!!! Thanks very much for pointing out this important step when checking GF status. Just need to get a resolution to [https://community.grommunio.com/d/1525-unable-to-login-to-some-mailboxes-with-web-client-following-todays-updates] so I can use the new error free GF in my live server.
Maxx
I am also on Debian 12 with grommunio and Nextcloud. Grommunio uses php8.2 therefore i disabled opchache for php8.2 and installed php8.3 in addition because it is possible to have opcache disabled for php8.2 but enabled for php8.3.
In the nginx vhost of Nextcloud i specified php8.3-fpm as my upstream php handler.
So this is my temporary workaround, until the bug with opcache is fixed in grommunio.
- Edited
It would be kind if you would see the opcache bug as it is and not as a grommunio bug. If you want all the details: https://docs.grommunio.com/kb/php.html#opcache
Having checked, it seems to still be an open issue with the latest opcache: https://github.com/php/php-src/blob/master/ext/opcache/jit/zend_jit.c#L2077C1-L2080C14
Feel free to ping the Zend guys... Unless it is not fixed, we unfortunately cannot bind to an accelerator which falsifies the important is_resource(...) call.