File upload nextcloud android

#1

Nextcloud version (eg, 12.0.2): 15.0.7
Operating system and version (eg, Ubuntu 17.04): raspbian (latest) kernel 4.14.98-v7+
Apache or nginx version (eg, Apache 2.4.25): nginx 1.10.3-1+deb9u2
PHP version (eg, 7.1): 7.0.33-0+deb9u3

The issue you are facing:
While trying to upload a file through nextcloud app on android (v3.6.0) the upload doesn’t start.

When I check the nextcloud.log file all I can see related to this is
“HEAD /remote.php/webdav/20171102-AH%20(53).pdf HTTP/1.0” 302 0 “-” “Mozilla/5.0 (Android) ownCloud-android/3.6.0”

My nextcloud server is behind a reverse proxy but have not encountered issues regarding this before.

When I do the upload through a webbrowser from my desktop it works instantly.

When I restart the php-fpm service the file seems to be uploaded anyhow .

Is this the first time you’ve seen this error? (Y/N): Y

Steps to replicate it:

  1. Upload file through android nextcloud
  2. Status on Android stays at 0%

The output of your Nextcloud log in Admin > Logging:

There is no output generated during the upload action.

The output of your config.php file in /path/to/nextcloud

<?php
$CONFIG = array (
  'instanceid' => '',
  'passwordsalt' => '',
  'datadirectory' => '/data/xxx/xxx/data',
  'dbname' => 'abc',
  'dbtype' => 'mysql',
  'dbhost' => '',
  'dbuser' => '',
  'dbpassword' => '',
  'version' => '15.0.7.0',
  'installed' => true,
  'forcessl' => true,
  'theme' => '',
  'maintenance' => false,
  'trusted_domains' => 
  array (
    0 => 'xxx.org',
  ),
  'check_for_working_webdav' => false,
  'loglevel' => 4,
  'secret' => '041602984278bee91befc3b0',
  'defaultapp' => 'calendar',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'filelocking.enabled' => 'true',
  'overwrite.cli.url' => 'https://xxx.org',
  'mail_smtpmode' => 'sendmail',
  'mail_sendmailmode' => 'smtp',
  'mysql.utf8mb4' => true,
);

The output of your Apache/nginx/system log in /var/log/____:

localIP - username [15/Apr/2019:18:39:49 +0100] "HEAD /apps/calendar/ HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Android) ownCloud-android/3.6.0"
localIP - username [15/Apr/2019:18:39:50 +0100] "HEAD /remote.php/webdav/20171102-AH%20(635).pdf HTTP/1.1" 302 0 "-" "Mozilla/5.0 (Android) ownCloud-android/3.6.0"
localIP - username [15/Apr/2019:18:39:51 +0100] "HEAD /apps/calendar/ HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Android) ownCloud-android/3.6.0"
localIP - username [15/Apr/2019:18:39:52 +0100] "HEAD /remote.php/webdav/20171102-AH%20(636).pdf HTTP/1.1" 302 0 "-" "Mozilla/5.0 (Android) ownCloud-android/3.6.0"
localIP - username [15/Apr/2019:18:39:53 +0100] "HEAD /apps/calendar/ HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Android) ownCloud-android/3.6.0"
localIP - username [15/Apr/2019:18:39:54 +0100] "HEAD /remote.php/webdav/20171102-AH%20(637).pdf HTTP/1.1" 302 0 "-" "Mozilla/5.0 (Android) ownCloud-android/3.6.0"
localIP - username [15/Apr/2019:18:39:55 +0100] "HEAD /apps/calendar/ HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Android) ownCloud-android/3.6.0"
localIP - username [15/Apr/2019:18:39:56 +0100] "HEAD /remote.php/webdav/20171102-AH%20(638).pdf HTTP/1.1" 302 0 "-" "Mozilla/5.0 (Android) ownCloud-android/3.6.0"
localIP - username [15/Apr/2019:18:39:57 +0100] "HEAD /apps/calendar/ HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Android) ownCloud-android/3.6.0"
localIP - username [15/Apr/2019:18:39:58 +0100] "HEAD /remote.php/webdav/20171102-AH%20(639).pdf HTTP/1.1" 302 0 "-" "Mozilla/5.0 (Android) ownCloud-android/3.6.0"
localIP - username [15/Apr/2019:18:39:59 +0100] "HEAD /apps/calendar/ HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Android) ownCloud-android/3.6.0"
#2

I can confirm similar behaviour with Nextcloud 16.0.1, Php 7.3, and version 3.6.2 of the Android app.

When I upload a file through the app (picture, text, whatever) it sits in the Current section of the Uploads page. The app indicates that it is “Uploading…” but makes no progress and it is not present in the files webapp (checked from another computer). However, when I ssh into the server that nextcloud is running on and restart php (i.e., systemctl restart php7.3-fpm.service), that is when it becomes available.

#3

I fixed it in my setup. Apparently supplying a custom 404 page in nginx.conf caused the issue. I commented out the line:

error_page 404 = /404.html;

and now everything works. The solution is taken from here:

It does seem odd that I cannot supply a custom 404 page, though.