• Feature-Request #5191826:
    Enable Direct File Streaming Download for Large Files in UniFi Drive Public Shares





    Hello Ubiquiti Support Team,

    I’m currently using UniFi Drive to share files via public links, and I’ve encountered a critical limitation:
    When downloading large files (e.g., ISO images), the browser returns:
    “This file exceeds the browser’s size limit.”

    This indicates that the download process is currently handled through a browser-managed buffer/JS blob rather than a direct streaming file transfer. Modern file delivery standards (as used by Microsoft, Google Drive, OneDrive, etc.) allow direct disk-streaming with HTTP range support, which removes browser memory limitations and supports large files well beyond 4GB.

    For real-world practical usage—especially among IT admins—UniFi Drive would greatly benefit from:

    1. Direct streaming downloads (server-to-disk)
      • Content-Disposition: attachment
      • Proper HTTP range support
      • Avoiding JS blob buffering in browser
    2. Resume-able downloads (Content-Range)
      • Allows partial downloads to resume after interruptions
    3. Option for direct download links in public shares
      • No UI wrapping layer or JS memory buffering required
    4. Optional guest access via WebDAV / SMB or client app
      • Allows large file transfers without browser constraints

    Currently, this limitation prevents sharing typical ISO files, firmware collections, and other large archives through UniFi Drive — which significantly reduces the practical usefulness of the platform.

    I strongly recommend enabling direct file streaming automation within UniFi Drive, as this would make the feature truly suitable for professional and administrative use cases.

    Thank you for your time and consideration, and I would appreciate any feedback or updates regarding this capability.

    Kind regards

  • Grendelbox December 3, 2025 at 10:33 AM

    Approved the thread.
  • fyi... :P



    Bedeutung von „(P)“ vor dem Ticket-Titel

    Das „(P)“ steht bei Ubiquiti-Supporttickets für „Priority“.
    Es signalisiert, dass dieses Ticket als priorisiert / wichtig / dringlich eingestuft wurde – entweder automatisch durch die Problemanalyse oder manuell durch einen Support-Mitarbeiter.
    Solche Tickets erhalten typischerweise schnellere Bearbeitung.

  • Grendelbox December 3, 2025 at 11:44 PM

    Changed the title of the thread from “UI Feature Request” to “UI Feature Requests”.
  • Feature-Request #5081342:
    URGENT – Incorrect Naming & Device Identification of Protect & Drive Devices in UniFi Network (Months Unresolved)


    Dear Ubiquiti Support Team,

    I am urgently requesting assistance regarding a long-standing issue with incorrect device naming and controller communication between UniFi Network and the other UniFi OS services (Protect & Drive).

    System environment:

    • UDM-SE – UniFi OS 5.0.5 / Network 10.0.162
    • UNVR-Pro – UniFi OS 5.0.5 / Protect 6.2.64
    • UniFi UNAS – UniFi OS 5.0.5 / Drive 3.4.4

    Issues observed:

    1. Protect and Drive devices appear in UniFi Network with incorrect names.
    2. Several cameras, chimes, and floodlights display wrong identities.
    3. The Power Protect icon is missing in some instances.
    4. Devices are often shown incorrectly in the client list instead of the device list.
    5. These issues have existed for many months and remain unresolved.

    I am one of the administrators of the German UI user forum:

    ubiquiti - Deutsches Fan Forum
    ubiquiti-networks-forum.de ist eine Plattform für Ubiquiti Produkte - Deutsche Fan Community
    ubiquiti-networks-forum.de

    Many of our users are losing patience, and there is significant frustration regarding these issues.

    They — and I — genuinely cannot understand why correct device names and version data from an external Protect/Drive controllers are not properly transferred into UniFi Network. This should not be complex — certainly not “rocket science.”
    Additionally, the incorrect classification of a UNAS-Pro in the client list instead of the device list seems like a basic structural error.

    We believe these are fundamental system basics that MUST function reliably.

    Examples of the incorrect naming and device representation are included in the attached documentation. I kindly request that this issue be thoroughly investigated and finally resolved, as it seriously impacts usability and device management.

    If necessary, I can provide remote debugging access or additional technical logs.

    Thank you in advance for your urgent support.
    Best regard

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!