iOS app can't play mp4 from SMB storage, browser can?

Nextcloud version (eg, 20.0.5): 27.1.5
Operating system and version (eg, Ubuntu 20.04): Univention docker based app

The issue you are facing:
I have some mp4 files stored on an SMB share that is connected to NC. I can download and play these files fine when logged in through a web browser. When logging in from the iOS app on my phone I get an error message.

Is this the first time you’ve seen this error? (Y/N): I don’t think this has ever worked in the app. I can’t remember when I first tried it, maybe NC 24 or 25. I only recently needed this functionality again and I thought I’d ask about it.

Steps to replicate it:

  1. Setup SMB share and add an .mp4 file
  2. Access share through web browser and make sure the file plays
  3. Try from the iOS app, and you should get an error message.

The output of your Nextcloud log in Admin > Logging:

No message shows up in the log when the error happens on the phone

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

<?php
$CONFIG = array (
  'passwordsalt' => 'xxx',
  'secret' => 'xxx',
  'trusted_domains' => 
  array (
    0 => 'ucs.mydomain.com',
    1 => '192.168.0.102',
  ),
  'datadirectory' => '/var/lib/univention-appcenter/apps/nextcloud/data/nextcloud-data',
  'overwrite.cli.url' => 'https://ucs.mydomain.com/nextcloud',
  'dbtype' => 'pgsql',
  'version' => '27.1.5.1',
  'dbname' => 'nextcloud',
  'dbhost' => '172.17.42.1',
  'dbport' => '5432',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'nextcloud',
  'dbpassword' => 'xxx',
  'installed' => true,
  'instanceid' => 'ocm4pkdyapr4',
  'updatechecker' => 'false',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'overwriteprotocol' => 'https',
  'overwritewbroot' => '/nextcloud',
  'htaccess.RewriteBase' => '/nextcloud',
  'ldapIgnoreNamingRules' => false,
  'ldapProviderFactory' => '\\OCA\\User_LDAP\\LDAPProviderFactory',
  'trusted_proxies' => 
  array (
    0 => '172.17.42.1',
  ),
  'loglevel' => 2,
  'maintenance' => false,
  'mail_from_address' => 'administrator',
  'mail_smtpmode' => 'smtp',
  'mail_domain' => 'mydomain.com',
  'mail_smtpsecure' => 'tls',
  'mail_smtphost' => 'mydomain.com',
  'mail_smtpport' => '25',
  'memcache.distributed' => '\\OC\\Memcache\\APCu',
  'theme' => '',
  'one-click-instance' => true,
  'one-click-instance.user-limit' => 500,
  'one-click-instance.link' => 'https://nextcloud.com/univention/',
);

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

172.17.42.1 - - [22/Dec/2023:15:19:08 +0000] "GET /nextcloud/remote.php/direct/pzR6Dxuou7ysp6kEnCr0Wzywjeg8Px4Gy2PdvVSXED2EAe2mZ16EgpQVhwo0 HTTP/1.1" 404 754 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/4.9.6"

Error on iOS says:

VLC is unable to open the MRL https://mydomain.com//nextcloud/remote.php/direct/pzR6Dxuou7ysp6kEnCr0Wzywjeg8Px4Gy2PdvVSXED2EAe2mZ16EgpQVhwo0

Just for clarification, that is just a problem when it is stored on the SMB share but not when it is in the main storage? And/or if it is shared or not?

I have the same issue (inability to play any videos unless download locally first) and it’s been going for better part of half a year. Ever since Nextcloud switched to new player in the iOS app. There are several bug reports about it, most recent one being Nextcloud App BUG REPORT - Your input can't be opened. VLC is unable to open the MRL · Issue #2658 · nextcloud/ios · GitHub

Thanks for the clarification, then it seems to be linked with the iOS client. I mark your answer as solution, since we need to wait for a solution from the developers. Please follow the topic on github to check for the status. Give a thumbs up on the main post, if you have the same issue (don’t just post a thumbs up or “me too”).

Is there any way to nudge developers to actively investigate this? as mentioned before there has been quite a few reports over the months with no visible progress, especially since things worked fine with older media player. (I saw in another github issue that developer refused to revert back to older media player but perhaps older media player can be brought back until the issue with the new one is resolved).

Best way is to buy an enterprise subscription, then you give them resources to do so. What makes the issue a bit difficult, for some it seemed to be linked to the webserver configuration and after that it worked for them, while it didn’t for others.

It can be the player, perhaps it is doing something differently. But also other things change between versions, so it can just be a coincidence. And such things are extremeley hard to debug, especially if you don’t have the issue yourself. E.g on my NC 27 (with nginx webserver) and iOS client, I can open mp4 files.
It can be stuff like the SSL errors (check if you have them in the logs as well, if not is there something else), it can be encoding, if data is buffered, if you use smb or other external storage or share, file name encoding, not the latest recommended webserver config, reverse proxies and cloudflare were often source of problems… Do it on “normal” storage, just to cut off other potential errors. Then you could try to connect to a server where it is working with other clients, and/or vise versa.

Under these conditions, you can perhaps understand why the developers don’t work 100% just on this issue or revert to previous versions. It probably works in their environment, and in many other environments as well. Then it is not a principal problem of the new player. It does not mean it is not annoying for you and you temporarily lost this functionality.

I just had an epiphany moment. Since I run Nextcloud via cloudflare tunnel it has hard limit on only accepting TLS 1.3 connections but iOS Nextcloud app doesn’t like that. Lowering it down to TLS 1.2 fixes the issues entirely!

I suspect there is still an issue with iOS app as it should work just fine with TLS 1.3 (it does on Android), so at least if you are running things behind Cloudflare make sure to set minimum TLS version to 1.2 in the meantime.

Just to let you know, if you add proxies en masse, your connection has to go through all these proxies, and all of these proxies need to agree on a cipher protocol for the encrypted connection between each other.

For just a browser, or just a webserver, you can use https://www.ssllabs.com to test against common browser versions. For the iOS client, I didn’t find a reference, not sure if that is the app or perhaps even fixed by the OS.

With these cipher settings in nginx, it works fine with my Nextcloud iOS app (even mp4 videos):

    ssl_protocols TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

I am using linuxserver docker image that comes with following defaults

# intermediate configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

When comparing to what you have I have same ciphers + 1 more DHE-RSA-CHACHA20-POLY1305;

I could try setting it to exactly what you have to see if that helps.

Alas nope, the moment I enforce TLS 1.3 only at cloudflare level, VLC starts throwing errors.

:thinking:

I’ve been trying to investigate this error further to see if it’s an SSL problem on my system. I can’t find any evidence of that. I have both TLS1.2 and 1.3 enabled and I don’t see any ssl error in the log.

Inside the docker container the apache log shows a 404 error.

“GET /nextcloud/remote.php/direct/iUBYYfhsAcGCDH7LZMm9V9O8iRmztUmant1koX7DtJoXJyrwKx0vfVzxUHan HTTP/1.1” 404 754 “-” “Mozilla/5.0 (iOS) Nextcloud-iOS/5.2.1”

If I try that URL directly in my browser I end up with a dav XML file error.

This XML file does not appear to have any style information associated with it. The document tree is shown below.

<d:error xmlns:d=“DAV:” xmlns:s=“sabre/dav”>

<s:exception>Sabre\DAV\Exception\NotFound</s:exception>

<s:message/>

</d:error>

<d:error xmlns:d=“DAV:” xmlns:s=“sabre/dav”>…</d:error>

I’m not sure where to go from here.

Just another note. When I go to one of these files in the browser the URL it uses to load the file is quite different and it works fine. It takes the form:

“GET /nextcloud/remote.php/dav/files/kevin/music/testfiles/test1.mp3”

I wonder why the difference exists.