Skip to content

PDF download/open fails (stuck at error) since 33.1.1, works fine in 33.1.0 #17211

Open

Description

@sergesr

⚠️ Before posting ⚠️

  • This is a bug, not a question or an enhancement.
  • I've searched for similar issues and didn't find a duplicate.
  • I've written a clear and descriptive title for this issue, not just "Bug" or "Crash".
  • I agree to follow Nextcloud's Code of Conduct.

Steps to reproduce

Description :
Downloading or opening PDF files fails consistently, both via explicit download and via tapping to preview/open. Images work fine (download and preview). The bug appeared starting with version 33.1.1 and is still present in 34.0.0.
Steps to reproduce :
Open any PDF file in the app (or tap "Download")
Download reaches 100% then fails with an error
Same PDF works fine when downloaded via the web browser interface

Environment :
Nextcloud Android app: tested on 33.1.1 and 34.0.0 (both fail), 33.1.0 works correctly
Server version: 33.0.5.1
Server log shows the GET request completing without error (HTTP request reaches the server fine, no exception, no error code) — issue appears to be client-side, after the file is received
Tested both with Play Store and F-Droid builds — same issue on both
Server hosted at Infomaniak
Additional notes :
Filename in test case included accented characters and spaces (e.g. "2025 10 optimisé.pdf"), though images with similar filenames work fine, so this may not be the root cause

Expected behaviour

PDF should download/open like it did in 33.1.0.
Actual behaviour :
Download/open fails at 100% for PDF files specifically. Images are unaffected.

Actual behaviour

Download/open fails at 100% for PDF files specifically. Images are unaffected.

Android version

16

Device brand and model

Honor 200 pro

Stock or custom OS?

Stock

Nextcloud android app version

Nextcloud Android app: tested on 33.1.1 and 34.0.0 (both fail), 33.1.0 works correctly

Nextcloud server version

Server version: 33.0.5.1

Using a reverse proxy?

I don't know

Android logs

No response

Server error logs

Additional information

No response

Activity

  1. FlopRe commented on Jun 20, 2026

    @FlopRe

    +1 this is an issue for me lately too. My workaround is to open nextcloud in the browser where pdf preview works just fine.
    Android 16
    Phone: 34.0.0 - Play store
    Server: 33.0.5 - Docker

    Previously downloaded PDFs (with the green tick) open up just fine obviously, but any new files that aren't caches locally get stuck on error occured 100%.

  2. thomasdelorge commented on Jun 27, 2026

    @thomasdelorge

    Following up on issues #17079 and #17157 : version v34.0.1 (released 3d ago) fixes this.

    I'm experiencing the same problem on one of my mobile devices : I'll give v34.0.1 a try and report back.

    EDIT : issue fixed 🥳

  3. nischg commented on Sep 8, 2026

    @nischg

    Still happening on 34.1.1 (latest F-Droid, added 2026-08-28), so this is not limited to 33.1.1/34.0.0 as originally reported.

    Device: Pixel 9a, Android 16 (stock)
    App version: Nextcloud Android 34.1.1
    Server version: 34.0.2
    Server setup: Behind Cloudflare Tunnel (cloudflared), Docker (nextcloud:latest image)

    Symptom: PDF download/open fails from the Files app (same behavior described above, appears to complete then errors out). Other file types (images) download fine.

    What I ruled out server-side:

    • Downloading the same file via a public share link works fine in a desktop browser (Firefox).
    • Checked response headers on the share download endpoint with curl (-L -D -): Content-Type: application/pdf, correct Content-Length, no Content-Encoding (Cloudflare is not compressing the PDF response, no transfer-encoding weirdness). Headers look completely standard.

    This points to the failure being purely client-side, consistent with what's already noted in this issue. Happy to provide more diagnostics (logcat, etc.) if it helps triage.

  4. veox commented on Oct 2, 2026

    @veox

    Can not reproduce with Nextcloud Android app 35.0.0, Android 16 (stock).

    Could this be due to a particular "Data storage location" setting?

  5. emutier commented on Oct 3, 2026

    @emutier

    Works for quite awhile again. Currently on 35.0.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions