So I did some more digging and turns out this was all due to my having botched the migration. I had used the experimental upgrader script, which kept failing due to timeouts, so I went ahead and tried to finish it up manually. With everything else apart from the Android app working as expected, I was fooled into thinking I had nailed it. But with this issue persisting, I just had to check, and wouldn’t you know, there were still all these files lingering from the previous Owncloud installation that I hadn’t replaced.

Tl;dr; re-downloaded 9.0.52, replaced the existing installation with the files extracted from the download, and the Android app now also connects without issue.

@HucSte, I’m not sure your issue is related, but if you also migrated from Owncloud, you could try re-installing Nextcloud files afresh.

Thanks @VicDeo, that indeed fixes it.

I’d argue that the comment above the setting in the sample makes this less than apparent — at least I would have been unlikely to have dared to set it to false on my own, and it still seems to me that in making this change I lose ”a crucial security check” for .htaccess. But that’s perhaps subject for another bug.

Upgraded to 8.2 today and the issue persists.

Upgraded to 8.1 today and the issue remains.

So I set up a Debian Wheezy VM just to test this, and was able to reproduce it straight away: did a clean install of 8.1 in /var/www/owncloud/ and set the data directory to /var/www/oc (whose owner I set to www-data:www-data). After installer was finished, selecting Admin from the Admin menu immediately causes ”File does not exist: /var/www/owncloud/data” to show up in error.log.

There was also this other error associated with it (copying here by hand instead because haven’t set up copy & paste in VM yet):

touch(): Unable to create file \\/var\\/www\\/owncloud\\/data\\/owncloud.log because No such file or directory at \\/var\\/www\\/owncloud\\/lib\\/private\\/log\\/owncloud.php#53

It would seem to hint the source of this being OC_Log_Owncloud::init (which is where the line it refers to belongs to AFAICT). For some reason this message about touch() failing does not show up on my actual installation’s logs (the one I pasted the logs from in the initial report above). It no longer seems to show up in the VM either after I raised logging level up to ”Errors and fatal issues”; not even after I lower it back down to ”Info, warnings, errors and fatal issues”; only the ”File does not exist: /var/www/owncloud/data” still keeps appearing. Perhaps the vanishing of that other message is also caused by the same problem with OC_Log_Owncloud::init.

Okay, I disabled all apps and the issue remains: the log still gets a new ”not exist” entry when I select ”Admin”.

Ha, got it! It’s the act of selecting ”Admin” from the ”admin” dropdown menu (top right) that triggers it. Nothing else seems to do it (”Users” from the same menu for example doesn’t trigger it).

There’s now also this in the log:

File does not exist: /var/www/userhome/mummila/sites/mummila.kapsi.fi/secure-www/oc/assets/dist, referer: https://mummila.kapsi.fi/oc/index.php/apps/gallery/

But I’d wager it’s completely unrelated to the other ”not exist”, as I only activated asset-pipeline yesterday. Browser’s JS log says it’s missing assets/dist/jquery-migrate.min.map; it doesn’t say anything about the data directory that the server log complains about.

While poking around, I also noticed that for my non-admin OC user, selecting Pictures from the Apps menu brings up the Pictures view, but it fails to load any pictures. The loading spinner just keeps spinning forever. The admin user’s Pictures view does work, i.e. it actually loads the pictures too. I’m not sure if this is related to the log issue either, but thought I’d mention it anyway.

Any ideas on how I can narrow this down further?

@schiesbn Sure. I’ve haphazardly tried it already, but I’ll give it a proper go sometime soon.

### Description
The Apache log file for my Owncloud site sporadically registers ”File does not exist: *[my OC root directory]*/data” errors from Owncloud; these go back to at least July last year (2014). To me this appears as if OC was erroneusly trying to access a hard-coded path for the data directory under the OC root, whereas my data directory actually resides elsewhere, entirely outside www my root, and there is no data directory under OC root.

The error timestamps indicate they only occur during daytime when I’m interacting with my installation (I’m the sole user), possibly only through the web interface, as I have the desktop client always on but the errors are rare relative to that. I use the web interface less and I think it corresponds to the timestamps better (but not all web interactions result in the error either, and I haven’t been able to pinpoint any specific action that triggers it).

Apart from those errors in the log my Owncloud installation appears work just fine, so the issue seems pretty harmless. I’ve considered creating an empty data directory under the OC root in case that might make the error go away, but then again it might just break something. Anyway, because it looks like a bug, I figured I’d better report it.

### Server configuration
**Operating system**: Debian Wheezy (I think; I’m a non-privileged user on shared hosting)

**Web server:** Apache/2.2

**Database:** MySQL 5.5.43

**PHP version:** 5.4.39-0+deb7u2

**ownCloud version:** 8.0.4.2

**Updated from an older ownCloud or fresh install:** updated

**List of activated apps:**
* Activity 1.2.0
* Deleted files 0.6.2
* External storage support 0.2.3
* First Run Wizard 1.1
* PDF Viewer 0.7
* Pictures 0.6.0
* Share Files 0.6.1
* Text Editor 0.4
* Updater 0.4
* Versions 1.0.5
* Video Viewer 0.1.3

**The content of config/config.php:**

”`
’datadirectory’ => ’/siilo/users/mummila/owncloud-data’,
’asset-pipeline.enabled’ => true,
’dbtableprefix’ => ’oc_’,
’dbtype’ => ’mysql’,
’forcessl’ => true,
’installed’ => true,
’logdateformat’ => ’l, j. F Y’,
’loglevel’ => 3,
’mail_smtpmode’ => ’smtp’,
’mail_smtpport’ => ’465’,
’mail_smtpsecure’ => ’ssl’,
’maintenance’ => false,
’max_filesize_animated_gifs_public_sharing’ => 5,
’preview_max_filesize_image’ => 5,
’session_lifetime’ => 60 * 60 * 24 * 15,
’theme’ => ”,
’version’ => ’8.0.4.2’,
”`

**Are you using external storage, if yes which one:** none

**Are you using encryption:** no

**Are you using an external user-backend, if yes which one:** none

### Client configuration
**Browser:** Chromium 37.0.2062.120 (build 281580)

**Operating system:** Ubuntu 12.04

### Logs
#### Web server error log
”`
[Sun Jun 14 13:57:52 2015] [error] [client 217.30.184.173] File does not exist: /var/www/use
rhome/mummila/sites/mummila.kapsi.fi/secure-www/oc/data
[Sun Jun 14 13:58:47 2015] [error] [client 217.30.184.173] File does not exist: /var/www/use
rhome/mummila/sites/mummila.kapsi.fi/secure-www/oc/data
[Sun Jun 14 14:29:18 2015] [error] [client 217.30.184.173] File does not exist: /var/www/use
rhome/mummila/sites/mummila.kapsi.fi/secure-www/oc/data
”`

#### ownCloud log (data/owncloud.log)

(No recent events coinciding with the log above. Last entry below, with my desktop IP address redacted, from two days ago)
”`
{”reqId”:”71513d1b6f44276a8cd6cad21bc98864″,”remoteAddr”:”[my desktop IP]”,”app”:”PHP”,”message”:”Undefined index: extension at \/var\/www\/userhome\/mummila\/sites\/mummila.kapsi.fi\/www\/oc\/apps\/files_versions\/lib\/storage.php#320″,”level”:3,”time”:”2015-06-12T04:37:22+00:00″}
”`

I’ve worked around that enum error (since before owncloud 7 already) by adding this in 3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Platforms/MySqlPlatform.php:

@@ -661,6 +661,7 @@
     protected function initializeDoctrineTypeMappings()
     {
         $this->doctrineTypeMapping = array(
+            'enum' => 'string',
             'tinyint'       => 'boolean',
             'smallint'      => 'smallint',
             'mediumint'     => 'integer',