That sounds more like a setup issue with your php
If you don’t specify a distrubuted cache we use the same as the localcache. This is where the double warning comes from. This is done so we have fewer code paths.
Following: Redirect Notice
Makes no mention of changing my PHP setup. I installed ACPu, enabled ACPu and popped the relevant config in config.php. So it should just work.
Well if your PHPinfo tells you that APCu is disabled then there is no way for Nextcloud to magically enable it of course 
I’m not an ubuntu user. But I’m sure there are guides for php7 for ubuntu on how to enable APCu
OK, it took some Googling, but essentially it looks as though the /etc/php/7.0/apache2/conf.d/20-apcu.ini file has only one entry:
extension=apcu.so
So I added the following based on three sources I found who’d configured it (plus a closed github issue from some random project):
apc.enabled=1
apc.enable_cli=1
apc.shm_size=128M
apc.ttl=3600
apc.user_ttl=7200
apc.gc_ttl=3600
Restarted apache, and now APCu is showing as enabled.
This likely needs documenting in the NC docs, along with recommended defaults for the above settings (and other settings if required, I think I’ve got the minimum listed there).
1 Like
Logs are now clean of APCu errors, so that was that.
It’d be interesting to know why installing and enabled APCu on PHP7 didn’t pre-populate the required fields as I presume it does in PHP5 (otherwise there’d be countless threads on this, right?).
There you need to ask the distribution which ships the packages for you. In most cases, manually added php-modules are enabled. PHP7 is quite new, and I’m not sure if all the caching solutions were available from the beginning (in a stable version). But that’s just a guess.
Indeed the module was enabled, but the required settings within the module to turn it on were missing.
I may need to add this to my guide.
Would anyone with a working APCu be able to provide their config at path/to/etc/php/module/apcu.ini or from their php.ini?
Bump.
Though the caching now works OK, I’d be happier knowing the APCu “default” settings I should be using.
Can you describe what you have done to make your caching works ?
Scroll up a bit and the post marked as the solution indicates what I added where.
Well, done the same thing, nothing more than the cache directory is generated 
Thanks anyway
Does NC report the cache being unavailable in the logs still for you?
I got nothing in the logs, just a cache directory with sub-directories named like the user of my cloud, but nothing in them.
An ls -l /path/to/user/cache shows 0, but ls -la indicates there are over 500 records for my main user account. I think it’s doing something, though maybe @rullzer or @tflidd can shine some more light on the subject.
Just have a look what the option -a stands for:
-a, --all do not ignore entries starting with .
the folder /path/to/nextcloud/data/user/cache is mainly used for uploads (client uploads chunks of files which are then assembled once all of them are received). Not sure if there is also other stuff. But in most cases the folder should be pretty empty unless you are uploading something.
APCU/redis manage their cache at a different location. Check the redis/apcu documentation if you are interested in more details (e.g. runtime information).
Indeed I know, usually running that shows everything in the directory but in this case it just tells me there are 500 records 
I figured APCu cache would be lumped in with the upload cache, so thanks for clarifying that!
No idea, perhaps some performance issue? You could select a more specific pattern to reduce the number of files: e.g. ls -la .a*. If this is new in Ubuntu 16.04, it should be documented somewhere, or search with the exact output for more information.
Just to be certain & for clarity, the newly edited apcu.ini file has:
extension=apcu.so
apc.enabled=1
apc.enable_cli=1
apc.shm_size=128M
apc.ttl=3600
apc.user_ttl=7200
apc.gc_ttl=3600
Thanks for finding this!
1 Like
Funny thing, now that I enabled debug log again, i realized the same info messages with the cron jobs every 15 minutes. But actually my phpinfo() shows “APCu Support Enabled” and also the main admin panel page does not show the expected error about missing memory cache.
I remember that I already had this in the past with owncloud, but as I am not wrong I handled the change of the apcu.ini as obsolete as apc.enabled=1 is set as default or something. But maybe the apc.enable_cli=1 is not and therefore the context app of the message is also “cli”?
EDIT: PHP: Runtime Configuration - Manual There it is: defaults are “apc.enabled=1” but “apc.enable_cli=0”.
This is what they say about the cli setting:
Mostly for testing and debugging. Setting this enables APC for the CLI version of PHP. Under normal circumstances, it is not ideal to create, populate and destroy the APC cache on every CLI request, but for various test scenarios it is useful to be able to enable APC for the CLI version of PHP easily.
This explains why it is not handles as error in nextcloud, just as info while running the cron jobs. Maybe someone can say something about the actual effect of this setting on nextcloud? But after all it seems to be okay for me to leave it disabled, as far as apc.enabled=1 of course (as is as default) and also phpinfo() shows proper APCu support.