TypeError Desktop Version

[transdata]

Support intro

Sorry to hear you’re facing problems.

The community help forum (help.nextcloud.com) is for home and non-enterprise users. Support is provided by other community members on a best effort / “as available” basis. All of those responding are volunteering their time to help you.

If you’re using Nextcloud in a business/critical setting, paid and SLA-based support services can be accessed via portal.nextcloud.com where Nextcloud engineers can help ensure your business keeps running smoothly.

Getting help

In order to help you as efficiently (and quickly!) as possible, please fill in as much of the below requested information as you can.

Before clicking submit: Please check if your query is already addressed via the following resources:

• Official documentation (searchable and regularly updated)
• How to topics and FAQs
• Forum search

(Utilizing these existing resources is typically faster. It also helps reduce the load on our generous volunteers while elevating the signal to noise ratio of the forums otherwise arising from the same queries being posted repeatedly).

Englische Version des Textes unten

Hallo,

nach Update auf die neuste Version Hub 10 (31.0.9) kann ich docx und zip Dateien nicht mehr in der Desktop Version runter laden.

Betriebssystem: Linux 3.10.0-1160.119.1.el7.tuxcare.els21.x86_64 x86_64

Nextcloud Hub 10 (31.0.9)

Datenbank MariaDB Version: 10.4.34 und 10.06.x

Das Update ist ohne Probleme durchgelaufen. Die Dateien liegen sowohl lokal vor, als auch auf den Server. Wenn man nun mit der Desktop Version die Dateien aufruft, werden alle angezeigt. Bei Klick auf ein Bild wird dieses auch direkt geöffnet bzw. es lässt sich runter laden. Klickt man aber auf eine ZIP Datei und docx Datei und möchte diese herunterladen, kommt die Meldung

„Die angeforderte Datei ist nicht verfügbar“

und die Datei verschwindet aus der Liste.

Sie ist aber im Ordner /files vorhanden. Rechte stimmen. Nach einen weiteren Aufruf der Dateiliste in Browser wird die Datei wieder angezeigt.

Cache wurde gelöscht, anderer Browser genutzt etc.

Im Protokoll findet sich folgende Zeile:

TypeError stream_get_meta_data(): Argument #1 ($stream) must be of type resource, string given

Ich habe dann eine neue Nextcloud Instanz separat installiert. Tatsächlich verhält sich auch die neue Installation auch so. Selbst die Demo docx lässt sich nicht runter laden.

Ist das ein Bug in der Version? Oder bin ich blind und die Dateitypen müssen noch erlaubt werden? Wenn ja, wo?

####schnipp## english version

Hello,

After updating to the latest version of Hub 10 (31.0.9), I can no longer download docx and zip files in the desktop version.

Operating system: Linux 3.10.0-1160.119.1.el7.tuxcare.els21.x86_64 x86_64

Nextcloud Hub 10 (31.0.9)

MariaDB database version: 10.4.34 and 10.06.x

The update ran without any problems. The files are available both locally and on the server. If you now access the files with the desktop version, all of them are displayed. Clicking on an image opens it directly or allows you to download it. However, if you click on a ZIP file or docx file and try to download it, the message “The requested file is not available” appears.

And the file disappears from the list.

However, it is present in the /files folder. The permissions are correct. After opening the file list again in the browser, the file is displayed again.

The cache was cleared, a different browser was used, etc.

The following line appears in the log:

TypeError stream_get_meta_data(): Argument #1 ($stream) must be of type resource, string given

I then installed a new Nextcloud instance separately. The new installation actually behaves the same way. Even the demo docx cannot be downloaded.

Is this a bug in the version? Or am I blind and the file types still need to be allowed? If so, where?

[transdata]

Der Fehler tritt in der Datei 3rdparty/sabre/dav/lib/DAV/CorePlugin.php in Zeile 179 auf.Die Funktion stream_get_meta_data() wird aufgerufen, aber das übergebene Argument ist vom falschen Typ. Der Fehler liegt im Originalcode der Nextcloud-App, genauer gesagt im sabre/dav-Framework, das Nextcloud für WebDAV verwendet.

Hat niemand sonst das Problem nach einen Update? Auch bei einer frischen Installation tritt dieses Problem auf.

The error occurs in the file 3rdparty/sabre/dav/lib/DAV/CorePlugin.php on line 179. The stream_get_meta_data() function is called, but the passed argument is of the wrong type. The error lies in the original code of the Nextcloud app, specifically in the sabre/dav framework that Nextcloud uses for WebDAV.

Is anyone else experiencing this issue after an update? This issue also occurs with a fresh installation.

[fafk_webmaster]

Ich habe das selbe Problem mit Nextcloud 31.0.9 & 32.0.0. Scheinbar unabhängig vom Dateityp.

Hoster ist DomainFactory.

Hast du mittlerweile eine Lösung gefunden?

############################

I have the same problem with Nextcloud 31.0.9 & 32.0.0. It seems to be independent of the file type.

My host is DomainFactory.

Have you found a solution yet?

[transdata]

Leider nicht. Ich finde auch keine Einträge diesbezüglich im Server Log. Irgendetwas in Nextcloud wurde verändert, womit die Server Umgebung nicht mehr klar kommt.

[tflidd]

This is just a problem with the desktop client, or via web-interface as well?

I just tried with a 31.0.9 and didn’t have any problems to download a *.docx with via FF browser.

With the metadata, is there a specific metadata-app used? If you said it was working before, was that NC 29.xx or an earlier version of NC 32?

Perhaps also worth trying on a different system, some security software might be involved as well (browser plugins, firewall etc).

[fafk_webmaster]

In my case it’s the web-interface … reproduced with with FF, Chrome, Edge and also on FF and Legacy-Browser for Android. So I don’t think it’s a browser-issue.

Downloading all files as ZIP on a public share works.

Perhaps a migration-step is missing.

I’m on 32.0.0 … no newer Version can be installed on stable-channel.

The only 3rd-party Apps that are installed are “Secrets” and “OCC web”.

Last working version was 31.0.6

[transdata]

Ich habs! Mich wundert nur, dass nicht alle das Problem haben. In der /3rdparty/sabre/dav/lib/DAV/CorePlugin.php muss in Zeile 179 folgendes ergänzt bzw ersetzt werden:

        if (is_resource($body) && (!stream_get_meta_data($body)['seekable'] || -1 === fseek($body, $start, SEEK_SET))) {

Der angegebene Code-Abschnitt in der Methode httpGet versucht, den Dateityp (Content-Type) eines Streams abzurufen. Der Fehler liegt darin, dass der Code stream_get_meta_data() direkt auf dem Stream-Handle ($body) aufruft, ohne vorher zu prüfen, ob $body tatsächlich ein Stream ist.

Der Fehler tritt auf, weil $body manchmal ein Stream-Handle (Resource) und manchmal ein String sein kann (wenn die HTTP-Methode HEAD ist). Die in PHP 7 eingeführte Funktion stream_get_meta_data() erwartet jedoch immer ein Stream-Handle.

Die Korrektur besteht darin, sicherzustellen, dass $body ein gültiger Stream ist, bevor stream_get_meta_data() aufgerufen wird, oder die korrekte Funktion für Strings zu verwenden, falls es sich um einen String handelt.

Da der Code bereits sicherstellt, dass $body entweder ein Stream-Handle oder ein leerer String ('') ist, muss nur eine zusätzliche Prüfung hinzugefügt werden.

###English

I got it! I’m just surprised that not everyone has this problem. In /3rdparty/sabre/dav/lib/DAV/CorePlugin.php, the following needs to be added or replaced on line 179:

if (is_resource($body) && (!stream_get_meta_data($body)[‘seekable’] || -1 === fseek($body, $start, SEEK_SET))) {

The specified code section in the httpGet method attempts to retrieve the file type (Content-Type) of a stream. The error is that the code calls stream_get_meta_data() directly on the stream handle ($body) without first checking whether $body is actually a stream.

The error occurs because $body can sometimes be a stream handle (Resource) and sometimes a string (when the HTTP method is HEAD). However, the stream_get_meta_data() function introduced in PHP 7 always expects a stream handle.

The fix is ​​to ensure that $body is a valid stream before calling stream_get_meta_data(), or to use the correct function for strings if it is a string.

Since the code already ensures that $body is either a stream handle or an empty string (‘’), only one additional check needs to be added.

[tflidd]

For code modifications and improvements, please check with the developers on github: GitHub - nextcloud/server: ☁️ Nextcloud server, a safe home for all your data

[fafk_webmaster]

@transdata

Thank you so much! Worked for me as well hope it get fixed soon by the developers

[plattreuter]

Does this issue persist for you in Nextcloud Hub 25 Autumn (32.0.1)? The mentioned code line looks to be unchanged in the source, so I assume replacing the line with the snippet is still needed?