Item(s) Not Found

[Tobias]

• You’re unable to access items that you yourself have set to private? If so, does this happen immediately upon creating them, or is there some delay?
  Immediately

• When the problem reoccurs, is it happening to newly-created items only, or to the same private items as before?
  Same items as before

[triplingual]

Omeka S
Version: 1.4.0

PHP
Version: 7.2.24
SAPI: fpm-fcgi
Memory Limit: 128M
POST Size Limit: 20M
File Upload Limit: 10M
Garbage Collection: Yes
Extensions: apcu, bz2, calendar, cgi-fcgi, Core, ctype, curl, date, dom, exif, fileinfo, filter, ftp, gd, gettext, hash, iconv, intl, json, libxml, mbstring, mysqli, mysqlnd, openssl, pcre, PDO, pdo_mysql, pdo_sqlite, Phar, Reflection, session, SimpleXML, sockets, SPL, sqlite3, standard, tokenizer, wddx, xml, xmlreader, xmlwriter, xsl, Zend OPcache, zlib

MySQL
Server Version: 5.5.5-10.2.10-MariaDB
Client Version: mysqlnd 5.0.12-dev - 20150407 - $Id: 3591daad22de08524295e1bd073aceeff11e6579 $
Mode: STRICT_TRANS_TABLES, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION

OS
Version: Linux 4.14.133-113.105.amzn2.x86_64 x86_64

[triplingual]

But our instance of the issue seems to have stayed away once it disappeared. Also, I don’t recall it being associated with every time an Item was marked as Private, only when CSVImport-ed as Private. But I could be wrong about the distinction.

[Tobias]

I’ve now set up a cronjob restarting apache every day. This doesn’t solve the problem but (hopefully) stops the effect.

[jflatnes]

That’s certainly less than ideal, but may work as a workaround… If you have updates to PHP available from your distribution, perhaps try updating PHP as an option? I’m noting these are both very similar versions; it’s possible this is a bug on that side of things.

[jflatnes]

@triplingual, @Tobias:

I believe we tracked this down: the relevant factor that’s the same between your servers is that you both have the apcu extension installed. There was an issue with Doctrine caching that could cause the permissions checks to basically get “stuck” at a certain permission level, so you saw results like this where one view indicated an item was visible and another acted like it wasn’t.

A fix for this problem is available in the just-released Omeka S 2.1.2.

[triplingual]

Cool! We’ll be on 1.4.x until the summer, but it’s good to know we aren’t likely to see this again after the summer upgrade.