S3 Primary Storage Not Working Properly - Certain files always error out

,

I am using S3 as a primary backend. Have tested this occurs on a standard file system as well.

[/details]

Nextcloud version (eg, 12.0.2): NC 14, spun up from Docker
Operating system and version (eg, Ubuntu 17.04): Manjaro, Latest on client side.
Apache or nginx version (eg, Apache 2.4.25): Using Nginx, haven’t checked exact version yet.
PHP version (eg, 7.1):

Using the exact setup specified here

The issue you are facing: Whenever I attempt to upload certain files (using the desktop client on Arch Linux, Daily Appimage), they simply fail to upload.

I have tested that uploading certain files work without issue using the desktop client and can see they display fine in the web panel.

I CAN upload the non-working files without issue on the web panel.

The file is a 27MB Wav file.

I believe the following client-side logs may be relevant.

remote.php/dav/files/rtisdale/") FINISHED WITH STATUS "OK"
[OCC::Folder::slotRunEtagJob 	Trying to check "https://nextcloud.roberttisdale.com/remote.php/dav/files/rtisdale/" for changes via ETag check. (time since last sync: 238 s)
[OCC::AccessManager::createRequest 	6 "PROPFIND" "https://nextcloud.roberttisdale.com/remote.php/dav/files/rtisdale/" has X-Request-ID "8bd3c422-bc90-4045-bb52-f67bf29da5c7"
[OCC::AbstractNetworkJob::start 	OCC::RequestEtagJob created for "https://nextcloud.roberttisdale.com" + "/" "OCC::Folder"
[OCC::WebFlowCredentials::slotFinished 	request finished
[OCC::WebFlowCredentials::stillValid 	Still valid?
[OCC::WebFlowCredentials::stillValid 	QNetworkReply::NetworkError(NoError)
[OCC::WebFlowCredentials::stillValid 	"Unknown error"

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

Steps to replicate it:

  1. Copy the file into the Nextcloud folder
  2. Wait for it to sync
  3. Failure.

The output of your Nextcloud log in Admin > Logging:

|Warning|Login failed: 'elricsfate' (Remote IP: '108.61.222.232')|2018-09-23T13:51:18+0200|
|---|---|---|
|Error|OCP\AppFramework\OCS\OCSException: Unable to send the invitation mail|2018-09-23T13:50:34+0200|
|Error|Swift_TransportException: Connection could not be established with host 127.0.0.1 [Connection refused #111]|2018-09-23T13:50:34+0200|

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'htaccess.RewriteBase' => '/',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'apps_paths' => 
  array (
    0 => 
    array (
      'path' => '/var/www/html/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 => 
    array (
      'path' => '/var/www/html/custom_apps',
      'url' => '/custom_apps',
      'writable' => true,
    ),
  ),
  'objectstore' => array(
        'class' => 'OC\\Files\\ObjectStore\\S3',
        'arguments' => array(
                'bucket' => 'LOLNOPE',
                'autocreate' => true,
                'key'    => 'LOLNOPE',
                'secret' => 'LOLNOPE',
                'use_ssl' => true,
                'region' => 'us-east-1',
                // required for some non Amazon S3 implementations
                'use_path_style'=>false
        ),
  ),
  'instanceid' => 'ocka6jyeiixj',
  'passwordsalt' => 'LOLNOPE',
  'secret' => 'LOLNOPE',
  'trusted_domains' => 
  array (
    0 => 'nextcloud.roberttisdale.com',
  ),
  'datadirectory' => '/var/www/html/data',
  'dbtype' => 'mysql',
  'version' => '14.0.0.19',
  'overwrite.cli.url' => 'https://nextcloud.roberttisdale.com',
  'dbname' => 'LOLNOPE',
  'dbhost' => 'db',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'LOLNOPE',
  'dbpassword' => 'LOLNOPE',
  'installed' => true,
);

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

PASTE HERE

Any other information I can provide that might be useful for this?

if so, please let me know and I’m happy to get it posted up.

I can say I replicated this same error on Windows but seem to get a different error

image

For whatever reason it finally gave a more descriptive error.

The issue was related to the Nginx Proxy container having a far too low max upload size.

See here for fix

1 Like