Tip
DSM 7.1 support is now available. NASDrop has been verified on real DSM 7.1 and DSM 7.2 hardware. The current SPK supports Intel/AMD 64-bit (x86_64) Synology NAS models running DSM 7.1 or later.
NASDrop is a self-hosted personal download portal for Synology DSM and Docker hosts. Paste a supported GigaFile, GoFile, Pixeldrain, or Buzzheavier signed direct link, and the storage server downloads the file directly.
Download the latest SPK release
Important
NASDrop is an independent, unofficial community project. It is not listed in Synology's official Package Center catalog and must be installed manually. It is not affiliated with, endorsed by, or sponsored by Synology, GigaFile, GoFile, Pixeldrain, or Buzzheavier.
Warning
Third-party service changes may break NASDrop. NASDrop depends on the websites and APIs operated by GigaFile, GoFile, Pixeldrain, and Buzzheavier. Those providers may change their policies, terms, authentication, URL formats, rate limits, APIs, or download mechanisms without notice. Such changes may cause some or all NASDrop download functions to stop working temporarily or permanently. Continued compatibility and uninterrupted availability are not guaranteed.
- Long multilingual filenames are limited by UTF-8 byte length instead of character count. Names exceeding 240 bytes are shortened with a stable hash while preserving extensions, including
.tar.gz. - Temporary segments and assembly files now use only the short job ID, never the original title. Existing named segments are migrated on resume without silently overwriting conflicting files.
- Destination collision names also respect the byte limit. For jobs failed with
File name too long, install the update and resume the failed job; no NAS files are deleted by the update itself.
- Interrupted range responses are validated and checkpointed before resuming. Each job keeps its transfer mode, and tiny files no longer request empty ranges.
- Pause now shows Stopping until the worker exits. Resume/delete cannot race the previous worker, and stopped verification cannot publish a completed download.
- Package shutdown stops transfer process groups and interrupts disk processing before saving paused jobs. DSM hardware update/restart verification is still required; power loss and forced termination cannot guarantee a completed checkpoint.
- GoFile file-server HTTP 429 responses now delay queued and running GoFile transfers using a shared cooldown, including
Retry-After. Other providers remain eligible subject to the normal disk/concurrency limits. Failed transfer requests no longer make eight immediate curl retries; resume retries preserved ranges, while GoFile cooldown retries are scheduled automatically. - Download-response filename headers are captured from the actual transfer when HEAD discovery fails. Raw cookies and response headers are not kept after processing.
- Password-entry forms and expanded verification details survive list refreshes. An expired session returns to login; malformed non-object JSON requests receive an error.
- Opening DSM through a private address uses the NASDrop HTTP listener. Public domains still preserve the HTTP/HTTPS protocol used to open DSM; HTTP is unencrypted, so use HTTPS through a reverse proxy for untrusted networks.
Important
Old unfinished .more fragments without a validated response range cannot safely be reused and may be downloaded again. Completed valid segments are retained. A locally calculated SHA-256 alone does not prove equality with the provider's original file; comparison requires a provider-supplied checksum.
- Distributed sign-in failures now trigger only a five-second global pause after 30 failures in 60 seconds; the existing per-client five-failure/15-minute protection remains unchanged.
- Settings now include an explicit DSM reverse-proxy mode. It trusts the rightmost forwarded client address only from a loopback proxy and applies changes without restarting NASDrop.
- When a loopback proxy sends forwarded headers while the mode is disabled, NASDrop warns in both Settings and the service log that clients share one login-throttle bucket.
- GigaFile pages containing multiple files now queue each original file instead of the provider-generated combined ZIP, and resolve each file's real response name before it enters the queue whenever possible.
- GigaFile markup variations and malformed size metadata now fail safely, while large batches are staggered without an artificial three-file or combined-size limit.
- Provider page and header probes now have bounded timeouts, stalled transfers stop cleanly and can be resumed, and redirects cannot escape to another host or protocol.
- Web responses now include browser security headers, and the temporary inspection cache is bounded to prevent unrestrained memory growth.
- Pixeldrain metadata requests now identify the active NASDrop package version instead of the obsolete
NAS Download Portal/0.4.2value. - Invalid ID and password rules and login-throttle wait times now have dedicated English, Korean, Japanese, and Chinese error messages.
- NASDrop API and saved job failures now carry stable error categories, so English, Japanese, and Chinese users see localized errors instead of Korean-only backend text.
- DSM launcher account-reset authority is limited to the first five minutes of its one-hour automatic-login session, and the in-memory session registry is capped at 256 entries.
- Provider downloads now refuse redirects from HTTPS to plain HTTP. 7-Zip archive passwords are supplied through standard input instead of appearing in the process command line.
- Public hostnames opened over HTTP now show a clear warning before login and inside the dashboard while preserving certificate-free HTTP access.
- DSM icon handoff values are now single-use: the browser exchanges one for a short-lived launcher session and the server rotates the handoff immediately.
- Login handling now rejects malformed request lengths, safely handles non-ASCII login input, bounds stale failure records, and ignores forwarded client addresses unless a local reverse proxy is explicitly trusted.
- API routes now behave consistently when a query string is present, job state files use restricted permissions, extraction has a six-hour safety timeout, and concurrent settings writes are serialized.
- Restores Korean CP949, Japanese Shift-JIS, and Chinese GB18030 filenames when legacy ZIP archives omit the UTF-8 filename flag, while preserving UTF-8 names and archive path-safety checks.
- Buzzheavier signed direct links copied with Copy download link are now accepted by the web portal and Android client.
- Buzzheavier link tokens are removed from the public job source and stored separately with restricted permissions so they do not appear in the job list or
jobs.json. - Expired Buzzheavier links now produce a provider-specific message asking for a newly copied link.
- The settings screen now combines parallel-download and per-file transfer controls into one compact half-width card with a single warning and save action.
- The DSM launcher now preserves the protocol used to open DSM, so an HTTP domain opens NASDrop over HTTP instead of forcing HTTPS.
- Downloads, segmented-file assembly, verification, and extraction now run inside a hidden
.nasdrop-tmpworkspace. Only the completed file or extracted folder is moved to the selected destination. - ZIP (including AES-encrypted ZIP), 7z, RAR, and TAR-family archives can be extracted automatically. Extraction can be selected for each job, and an archive password can be entered when adding a job or after NASDrop detects that one is required.
- Disk protection can pause new downloads while verification or extraction is using the disk heavily.
- GigaFile filenames are resolved from the real download metadata so the queue can show the final filename before completion whenever the provider supplies it.
- The DSM launcher is validated during packaging so its desktop label remains
NASDrop.
Note
ALZip EGG archives are not supported for extraction. If an .egg file is downloaded, NASDrop saves it in its original .egg form even when extraction was requested. Extract it later with a separate EGG-compatible application.
- Validates GigaFile, GoFile, Pixeldrain, and Buzzheavier signed direct links and displays file names and sizes
- Queues multiple download jobs
- Supports a per-job destination folder and a configurable default folder
- Offers either an 8-part verified download or a lower-disk-I/O single-connection download
- Keeps partial files and assembly work inside a hidden
.nasdrop-tmpworkspace, then publishes only complete results - Can extract ZIP (including AES), 7z, RAR, and TAR-family archives with an optional per-job password
- Pauses new downloads during verification and extraction when disk protection is enabled
- Displays progress, failure details, and SHA-256 results
- Supports pausing, resuming, and deleting jobs, plus clearing completed jobs in bulk
- Protects direct browser and client-app access with an ID, hashed password, login throttling, and time-limited sessions
- Detects GoFile rate limits and uses a persistent cooldown circuit breaker
- Runs as either a native Synology SPK or a multi-platform Docker container on amd64 and arm64 hosts
The default 8-part download + verification mode downloads eight byte ranges in parallel, combines them locally, checks the final size, tests ZIP archives, and calculates SHA-256. It provides stronger integrity checking but can require substantial disk I/O after a large download finishes.
The optional Single connection mode writes one resumable temporary file without splitting or merging it. The shared post-processing pipeline still checks the final size and SHA-256 and performs archive validation when applicable. This lowers connection pressure while preserving integrity checks. The selected mode applies to new and resumed jobs.
backend.py: Authentication, link inspection, and the storage-local download queuegofile_wt.mjs: Helper for generating GoFile web tokenssynology/: DSM SPK metadata, web UI, lifecycle scripts, and build toolsDockerfile,compose.yaml, anddocker/: Portable container image, Compose example, and startup/account utilitiesconfig.example.json: Example package configurationruntime/: Hashed account credentials, sessions, configuration, logs, and job state; excluded from Gittests/: Python and Node.js regression tests for providers, packaging, authentication, extraction, and the rendered UIdocs/: Release, provider-filename, and DSM-launcher regression checklistsassets/: Documentation screenshots and translated setup guides.github/: Release and container publishing workflows
- Open the latest GitHub release and download the
x86_64.spkasset. - In DSM, open Package Center > Manual Install.
- Select the downloaded SPK and review the manual-install warning and license.
- Complete the installation, then grant the NASDrop package account access to a destination folder as described below.
The package supports DSM 7.1 or later on Intel/AMD 64-bit (x86_64) Synology NAS models. DSM 7.1 and DSM 7.2 have both been verified on real hardware. ARM models are not supported yet. Because this is not an official Package Center listing, GitHub releases are the only supported distribution channel and updates are installed manually.
NASDrop does not select a default download folder during installation. A download cannot start until a writable destination is selected either as the default destination or for that individual job.
Important
After every update, open NASDrop Settings and select the default download folder again before adding new jobs. Even if the previous path still appears, reselect it once so NASDrop can confirm that the package account still has write permission.
When upgrading from an older release, the former automatically assigned /volume2/downloads value is cleared. A different destination that was explicitly selected by the administrator may remain visible, but it should still be selected again after the update as described above.
The Docker image is suitable for Synology Container Manager, ordinary Linux servers, home servers, and Docker Desktop. Published images target both linux/amd64 and linux/arm64.
-
Download
compose.yaml. Optionally copydocker/compose.env.exampleto.envwhen you want to override the defaults. -
If you created
.env, setNASDROP_CONFIG_DIRandNASDROP_DOWNLOAD_DIRto persistent host folders. -
On Linux or Synology, set
PUIDandPGIDto the numeric user and group that can write to the download folder. You can find them withid your-user. -
Create the first NASDrop account interactively. The password is prompted without being placed in the command line or Compose environment:
docker compose run --rm nasdrop account set owner -
Start NASDrop and open
http://SERVER-IP:8791:docker compose up -d
-
Sign in, open Settings, and select the default download folder once so NASDrop verifies write access.
The default Compose configuration persists application state in ./nasdrop-config, mounts ./downloads as /downloads, and stores partial files in /downloads/.nasdrop-tmp. Recreating or updating the container does not remove those host folders.
To reset the login later, run the account command against the running container and restart it:
docker compose exec nasdrop nasdrop-account set owner
docker compose restart nasdropContainers can only browse host folders explicitly mounted into them. To expose more destinations, add each bind mount and list every container path in NAS_PORTAL_STORAGE_ROOTS:
services:
nasdrop:
environment:
NAS_PORTAL_NAS_TARGET: /downloads
NAS_PORTAL_STORAGE_ROOTS: /downloads,/media,/archive
volumes:
- /srv/downloads:/downloads
- /srv/media:/media
- /mnt/archive:/archiveNASDrop never recursively changes permissions on mounted download folders. If the container reports that a folder is not writable, adjust the host folder for the configured PUID:PGID; do not run the service as a privileged container. Only /config is automatically assigned to that numeric account.
Update without deleting persistent data:
docker compose pull
docker compose up -dAfter an update, open Settings and select the default download folder again. For access outside the local network, place NASDrop behind an HTTPS reverse proxy and do not expose plain HTTP port 8791 directly to the internet.
- Sign in to DSM with an account that is allowed to open NASDrop, then launch it from the DSM desktop or Package Center icon. The icon provides a one-time privileged handoff that can create or reset the NASDrop login.
- After installing or updating, use that DSM icon launch and create a NASDrop ID and password under Settings > Client connection. Only grant NASDrop application access to DSM users who are allowed to reset this login.
- Opening the service address directly, using another browser, or connecting a client app requires that ID and password.
- If the ID or password is forgotten, sign in to DSM, open NASDrop from its DSM icon, and reset both values under Settings > Client connection. The old password cannot be displayed or recovered.
- Passwords are stored only as salted PBKDF2-SHA256 hashes. Successful logins receive a time-limited session token; changing the account credentials revokes existing sessions.
- Five consecutive failed login attempts from the same client IP trigger a 15-minute login block.
The DSM launcher uses a separate one-time browser handoff value and removes it from the address immediately. The server exchanges it for a short-lived launcher session, rotates the handoff at once, and never treats the value embedded in the launcher file as a reusable API credential.
The following guides show how an authorized DSM user creates the first NASDrop ID and password and how the DSM icon launch can reset existing credentials.
English
한국어 (Korean)
日本語 (Japanese)
简体中文 (Simplified Chinese)
Build the SPK with Windows PowerShell and Python 3.11 or later. The build tool packages DSM shell scripts with LF line endings and executable permissions, then validates the resulting archive.
.\synology\build-spk.ps1The output is synology/dist/nasdrop-0.9.13-1-x86_64.spk. Building from source does not make the package an official Synology Package Center application.
Release validation details are in docs/RELEASE_CHECKLIST.md. Provider filename handling and DSM launcher-title rules are documented in docs/PROVIDER_FILENAME_GUIDE.md and docs/DSM_LAUNCHER_GUIDE.md so those regressions are checked before future releases.
- In DSM, open Control Panel > Shared Folder.
- Create a shared folder or select an existing one, then click Edit > Permissions.
- Change the permission category to System internal user.
- Find the NASDrop package account, commonly displayed as
sc-nasdownloadportal, and grant it Read/Write permission. - Open NASDrop, go to Settings > Default destination > Change, and select the writable shared folder.
Folders without package-account permission appear locked or cannot be selected. If an encrypted shared folder is used, mount it before starting NASDrop. You can also leave the default empty and choose a writable destination separately for each download job.
See Synology's official guides for creating a shared folder and assigning shared-folder permissions.
English is the default interface language. NASDrop automatically follows the browser language when it is Korean, Japanese, or Chinese. It falls back to English when the language is unsupported or cannot be detected.
Users can manually select English, Korean, Japanese, or Chinese on the login screen or from the top navigation. The selection is stored in the browser. DSM Package Center descriptions support the same four languages.
The interface and categorized server errors are translated into all four supported languages. Unclassified provider diagnostics use a localized generic fallback outside the Korean interface.
NASDrop listens on plain HTTP port 8791 inside the NAS. For internet access, keep that application port private and terminate HTTPS with DSM's built-in reverse proxy.
- Open Control Panel > Login Portal > Advanced > Reverse Proxy and click Create.
- Configure the source:
- Protocol:
HTTPS - Hostname: your public hostname, such as
nas.example.com - Port:
8443
- Protocol:
- Configure the destination:
- Protocol:
HTTP - Hostname:
127.0.0.1 - Port:
8791
- Protocol:
- Save the rule.
- Open NASDrop > Settings > Service address, enable Use DSM reverse proxy, confirm that NAS port
8791is not exposed directly to the internet, and save the connection settings. This separates login throttling by the client address supplied by the local DSM proxy. - Open Control Panel > Security > Certificate > Settings and assign a valid certificate for the public hostname to the new reverse-proxy service.
The screenshots below show the configuration currently used in the maintainer's own environment. They are provided as a working reference, not as values that must be copied exactly. Replace the hostname and NAS IP address with the values for your own network.
In this environment, the router forwards external port 8791 to port 8443 on the NAS at 192.168.1.157. The router is set to BOTH; TCP alone is sufficient for NASDrop.
The DSM reverse-proxy rule receives HTTPS on port 8443 and forwards it to the NASDrop HTTP service at 192.168.1.157:8791.
Select a language to view both configuration screens. The localized copies are visual translations of the same settings; menu wording may differ slightly depending on the router firmware and DSM version.
English
한국어 (Korean)
日本語 (Japanese)
简体中文 (Simplified Chinese)
The actual source hostname has been hidden in the screenshot. Enter your own certificate hostname in that field. A matching wildcard certificate, such as *.example.com, can be assigned to the rule. For the destination hostname, either 127.0.0.1 (recommended) or your NAS LAN address can be used.
If the public address must remain https://nas.example.com:8791, configure the router to forward external TCP 8791 to NAS TCP 8443. The complete request path is:
Internet HTTPS :8791 -> router -> NAS HTTPS :8443 -> DSM Reverse Proxy -> HTTP 127.0.0.1:8791
If the router uses a different external port, such as 8795, open NASDrop > Settings > Service address and set DSM icon external port to the same value. The DSM icon will then open https://your-public-hostname:8795, while private LAN launches continue to use the internal NASDrop port 8791.
The following screenshots show the new port setting in all four supported interface languages. The public hostname is intentionally hidden.
English
한국어 (Korean)
日本語 (Japanese)
简体中文 (Simplified Chinese)
Do not forward any external port directly to NAS port 8791; that would expose login credentials and portal traffic over unencrypted HTTP.
After saving the configuration, test the exact HTTPS address from outside the local network. A request beginning with http:// will return 400 Bad Request because plain HTTP was sent to an HTTPS listener.
The DSM launcher preserves the protocol used to open DSM. It uses port 8791 for private hosts and the external icon port selected in NASDrop settings for public hostnames. See Synology's official DSM Reverse Proxy documentation.
Login throttling uses the direct peer address by default and does not trust X-Forwarded-For. Behind DSM Reverse Proxy, enable Use DSM reverse proxy under NASDrop > Settings > Service address; otherwise every proxied client shares the loopback address and therefore one login-throttle bucket. NASDrop accepts the rightmost forwarded address only from a loopback proxy and records both peer and selected client addresses in its log. Docker users can set NASDROP_TRUST_FORWARDED_FOR=true instead. Never enable this mode when untrusted clients can reach NASDrop port 8791 directly.
Five consecutive failures from one client still block that client for 15 minutes. Separately, a distributed burst of 30 failed sign-ins within 60 seconds pauses all new sign-in attempts for only five seconds; it never creates a global 15-minute account lock.
python -m py_compile backend.py
python -m unittest discover -s tests -p "test_*.py"
node --test tests/rendered-html.test.mjs tests/gofile-wt-sandbox.test.mjs- Keep runtime credentials and device-specific configuration private.
- Never commit
runtime/,.env*, signing keys, or device-specific secrets. - The local
service.logrecords timestamps, client IP addresses, HTTP methods, endpoint paths without query strings, and response status codes for diagnostics. Each log file is limited to 1 MiB and only two rotated backups are retained (about 3 MiB maximum total). - Use HTTPS whenever the portal is accessible from the internet.
- When NASDrop is opened over HTTP on a public hostname, the login screen and dashboard show an unencrypted-connection warning. HTTP remains available for certificate-free or trusted-network setups; the warning does not appear for private IP addresses, localhost, single-label NAS names, or
.localhosts. - Consider an additional access-control layer beyond the NASDrop account login for internet-facing deployments.
- NASDrop does not require DSM administrator passwords or NAS account credentials in the web interface.
- Only submit links and download files that you own or are authorized to access. You are responsible for complying with the source service's terms and applicable law.
- JSON API request bodies are limited to 16 KiB and idle request handling times out after 30 seconds.
- Login failure tracking retains inactive entries for 15 minutes and is capped at 4,096 client addresses.
- Browser login sessions last seven days; DSM launcher sessions last one hour, while the handoff that creates them is single-use.
- Archive extraction is stopped after six hours. Archive safety checks also cap entries at 100,000 and extracted data at 1 TiB.
- Individual source files are limited to 300 GiB, and the global download scheduler runs at most three jobs concurrently.
NASDrop currently supports standard GigaFile links, GoFile share links, Pixeldrain file-share links, and Buzzheavier signed direct links copied from the provider page. For Pixeldrain, it compares the SHA-256 value reported by the public API with the final downloaded file hash.
A normal Buzzheavier share URL such as https://buzzheavier.com/FILE_ID opens the provider page; it is not the direct file URL that NASDrop needs. Use the following steps:
- Open the normal
https://buzzheavier.com/FILE_IDshare page in a regular browser. - On the real Buzzheavier file page, select Copy download link. Do not copy an advertisement button or the browser address bar URL again.
- Confirm that the copied address begins with HTTPS, uses a Buzzheavier download host, contains
/d/FILE_ID, and still includes its complete?v=...query value. - Paste that copied address into the NASDrop web portal or Android app. You may then choose a destination folder and extraction option normally.
- Add the job promptly. NASDrop inspects the signed link and the NAS downloads the file directly; the browser or phone does not relay the file data.
The address accepted by NASDrop has a form similar to:
https://DOWNLOAD-SERVER.buzzheavier.com/d/FILE_ID?v=SIGNED_TOKEN
For example, submit the copied https://ts.buzzheavier.com/d/...?... style address—not the original https://buzzheavier.com/... page address. Do not remove or shorten the query string: the complete v value is required to authorize the file request.
Verified Buzzheavier responses provide the final filename through Content-Disposition, the file size through Content-Length, and byte-range support for segmented downloads and resume.
The v value is a signed, potentially time-limited token. If NASDrop reports that the link has expired, is unauthorized, or no longer resolves to a file, return to the original share page, select Copy download link again, and submit the newly generated address. Repeatedly retrying the expired address will not refresh it.
Caution
Treat the complete copied URL as private while it remains valid. Do not post it in public issues, screenshots, chat logs, or documentation. When reporting a problem, remove the entire query string or replace the token with ?v=REDACTED. Keep the original share-page address so you can generate a fresh signed link later.
NASDrop does not automate Buzzheavier's advertisement page or imitate clicks on the provider page. The user obtains the final link in a normal browser, while the NAS performs only the resulting direct file transfer. Only download files that you own or are authorized to access.
When GoFile returns HTTP 429, NASDrop immediately blocks additional GoFile requests and stores the cooldown deadline in persistent state. The cooldown survives service restarts, preventing repeated retries from making an IP restriction worse. Link-inspection logic may require updates when an external service changes its website or API behavior.
External download services may rate-limit or block the NAS public IP when they receive too many link inspections, download attempts, parallel connections, or rapid retries. This can result in HTTP 429 responses, temporary access restrictions, or a longer IP-based block. NASDrop cannot remove a restriction imposed by an external service.
To reduce the risk:
- Keep parallel downloads from the same service disabled unless they are necessary.
- Do not repeatedly submit the same link or restart NASDrop to bypass a displayed cooldown.
- When NASDrop reports a protection pause, wait until the displayed cooldown has fully expired.
- Avoid testing the same external service simultaneously from multiple tools or devices on the same public IP.
- If access is already restricted, stop all automated requests and allow sufficient time for the external service to release the restriction.
NASDrop processes jobs from the same provider sequentially by default and preserves GoFile cooldown state across service restarts. These protections reduce request volume, but they cannot guarantee that an external service will not apply its own limits.
- For installation problems, provider compatibility, and other non-security bugs, open a GitHub issue.
- For vulnerabilities or reports containing sensitive details, follow SECURITY.md and do not open a public issue.
- Include the NAS model, DSM version, NASDrop version, relevant logs with account credentials, session tokens, and private URLs removed, and clear reproduction steps.
External services may change without notice. Compatibility fixes are provided on a best-effort basis, and this unofficial package has no support relationship with Synology or the supported download services.
NASDrop is released under the MIT License. Bundled third-party components retain their own licenses; see THIRD_PARTY_NOTICES.md.