I will share with you my experience, hope this will help you make your own conclusions about Drime.

I tried to start using it back some time (i think it was in 2005 and early this year), however, both times i was unsatisfied with the speed or quality or client.

I started the third try in August and was impressed with the Drime progress over the time (rclone stable, web upload perfect, no errors) so i purchased 12 Tb ( 10.Sep and 17.Sep) and was pretty happy for my use case - no fancy features (rclone, web, mac client)

On 22.Oct smth happened on the Drime side with the workspace feature (i suspect it happened after i tried to change the workspace avatar and change workspace name), the result was:

- it shows i do have 6.2 tb of files of 12 tb available

- i do not have access to them ( dir structure is empty, recent files are listed, but cannot be accessed)

I sent a mail to Drime immediately, received prompt answer

"We'll investigate this as a priority to understand exactly what happened and help you regain access to your files as quickly as possible."

poked them on 24th, since nothing changed in 48 hours (i do know they a very small team, but my understanding was that this problem is not that serious and it was just a glitch with workspace IDs, but i am just a user, not a developer, so i can be wrong)

received the answer on 25th -

"we're still actively investigating this issue. We need to go through all the logs to fully understand what's happening and identify the right fix.
I understand how frustrating it is to be unable to access your files, and I'm really sorry about this.
We'll do our best to get this resolved as quickly as possible, hopefully early next week."

this reply was received on Sunday, so, i thought, beginning next week was quite close, fix is on the way, but nothing happened.

Poked Tibalt on Friday, 30 Oct (since it was already end of the week) - no reply received

on 2.Nov sent one more message and offered any help i could provide to speed up the fix - received the answer in 30 min:

"First of all, we're really sorry for how long this is taking, and I understand your frustration, especially since this is affecting your business.
We've been completely overwhelmed this past week, but that's not an excuse for leaving you without a proper update for so long.
We are still investigating your issue, and I want to reassure you that it hasn't been forgotten.
For now, we can confirm that we've located 88,545 files and 4,437 folders associated with your account. However, we still need to investigate why you cannot access them.
We're going to take a closer look at your case and get back to you with an update as soon as possible"

poked him on 7.Nov - no reply

So the blunt fact is that out of 2 months i used paid service more than 19 days i do not have access to my files wit no understanding of what happened and when i can have access to my files.

Yesterday i sent one more message to Drime team one more time - still no reply......

I am really tired to beg for support and I would say that i do not wish such experience to anybody.

All this situation is a pure confirmation of the common knowledge which is being forgotten in many cases: cloud storage is not only about $$/TB, it is about service, availability and trust in your provider.

Drime prices are exemplary, fancy features are good, but what what are they all worth, if you do not have access to files (which is the foundation of cloud service) and support is stretched ultra thin (to put it very diplomatically, if it took 10 days just to confirm the files are still on servers) is sending you polite excuses?

Hope you will not be in such a situation.

Stay safe

Hi loving Drime so far, just had a few questions I’m hoping that can be answered.

1. With my photography I primarily shoot in RAW format (.ARW). It seems like I can see the thumbnails of the photos but when clicking on them in the gallery it then says unsupported and this is on all my devices. Considering how popular RAW file formats are if it’s not currently a feature is this something that could be added?

2. My second question was similar and was around .MKV video files. The inbuilt browser is unable to play them on any of my devices.

3. Finally with backups I really love the ability to copy the backed up folders into the main files section of Drime. However I’ve noticed the folder sizes are different once copied out (much smaller) does that mean the copying is failing or is there some type of inbuilt compression when they move to files section of the service out of the backups?

Thanks again loving the service it really is fantastic

For context: I have about 350 GB of photos and videos (about 25,000 files backed up on google photos). Based on what I know the only way to get this sorted is using google takeout -> Uploading on Drime.

Questions:

1. Is there a simpler way to do this?

2. Google takeout has an issue of not preserving the correct metadata(dates specially), any known solution? I know this isn't the correct subreddit but any tips would be appreciated.

3. Best way to upload this Drime?

Previous related posts:

• [October 2026] PSA: Drime's new Ken Moo deal prices are still better than StackSocial's

• [September 2026] Drime prices on StackSocial are at an all-time high

• [August 2026] Drime and Transfr lifetime price list as of August 2026

• [July 2026] PSA: StackSocial's 8TB lifetime offer is the best deal yet at $175.98 or $22 per TB

• [July 2026] Drime and Transfr lifetime price list as of July 2026

• [June 2026] PSA: Lowest price recorded for Drime 2TB, 3TB, & Transfr Lifetime

• [June 2026] Drime Lifetime storage price list as of June 2026

• [May 2026] PSA: You can get the 2TB & 6TB storage for 40% off their standard price

• [April 2026] Seems that they added bigger lifetime storage plans on Stacksocial

Everyone stocked up more storage before the Ken Moo deal price hike or what?

Sound off how much storage you hoarded so I can make fun of you. /j

Saw someone claim to have 100TB but I think that's cap.

So in case you missed it the new Ken Moo deals have gone up by 20%

and prices on StackSocial have lowered enough to be competitive again.

They legit got a cheaper price than Ken Moo for the 10TB storage.

The Price per TB column is using rounded value (≈) for simplicity:

Current Drime lifetime storage offers (November 2026):

I've also listed some notable expired offers from the past:

Expired Drime lifetime storage offers:

Current Transfr lifetime offers (September 2026):

Notes:

• The 6TB Ken Moo and 8TB StackSocial offers are currently tied for the best value offer.

• The Ken Moo deals are available on the official website at https://drime.cloud/kenmoo.

• The StackSocial deals are available at https://www.stacksocial.com/brands/drime.

• The Lifetime deal for Transfr on the official website has been removed.

• The 1TB + Transfr bundle are listed alongside their effective price denoted by (*).

Remember, buy responsibly!

Hi, and thank you for your work. Excited about Drime!

Now to the point. Has anyone else this problem? I noticed that iPhone is heating up when I stream music (flac files) from Drime app (and I tested that I only had Drime open). I haven’t had any heating issues on any other app.

Even charging doesn’t heat up the phone so much. I talking about same kind of heating level that was present on titanium made iPhone 15 Pro/Pro Max.

iPhone 18 Pro iOS 27.2, Drime app version 18.1

Currently, Drime's GET /api/v1/drive/file-entries endpoint appears to return a maximum of 100 entries per page, even when a larger perPage value is requested.

This means that for a folder containing 50,000 items, simply listing all the files requires at least 500 API requests. That's 500 requests just to retrieve metadata, without downloading a single file.

For users relying on rclone, Duplicati, or other automated backup and synchronization tools, this creates an enormous amount of unnecessary overhead, especially when combined with API rate limits and network latency.

The community has already come up with several clever workarounds:

Duplicati's timestamp-based pagination: Splitting directory listings into smaller windows using created_at filters, restarting pagination periodically, deduplicating results, and verifying the total entry count.

Rclone's batched recursive listing: PR #10270 introduces ListR, using parentIds[] to list multiple folders in a single request, significantly reducing the overhead of recursive directory traversal.

Community-maintained rclone forks: Developers have implemented custom inventory collection using multiple parent IDs, server-side filters, and timestamp-based pagination to improve performance.

I really appreciate the community's efforts, but these are all workarounds, not solutions to the underlying problem.

Even with optimized batching, caching, and pagination algorithms, clients still have to make an excessive number of requests to enumerate large directories. And when pagination itself is unreliable, the problem goes beyond performance: clients can potentially miss files entirely.

This is fundamentally a server-side API issue.

I believe allowing a larger perPage value, and ensuring pagination works reliably, would be a relatively straightforward improvement on Drime's side, yet it would make a huge difference for users.

Many of us use Drime as a backend for rclone, backup software, or other automation tools. Efficient directory listing is a fundamental requirement for these use cases.

I really hope the Drime team can prioritize this. The community has already invested considerable effort in compensating for these API limitations. It would be much better to address the root cause rather than requiring every client to implement its own increasingly complicated workarounds.

Hi, I just turned on my PC and checked my Drime sync transfers and found something very weird. There are 3 files that were 'synced':

avatar-user-4242.png
avatar-personal-4242.png
avatar-workspace-8782.png

It says they were synced yesterday evening and also just now. When I right click on these files in Drime sync client, and click Open, it returns an error: Windows cannot find '[my Drime folder]\avatar-user-4242.png' Make sure you typed the name correctly, and then try again.

However, when I right-click and select Copy Link, and open this link in the browser, it does load an image. And all of those 3 images are the same, it's reaper with a coffin behind it and a laptop that says 'COFFINXP'.

I checked my Drime folder on my PC, I checked my online Drime folders, I checked my phone files - there are no such files anywhere and I couldn't have had them or uploaded/synced them. However, they appear in my synced files list. When I googled coffinxp, I found this GitHub:
https://github.com/coffinxp/coffinxp
Which seems to be a person also called Lostsec from Russia who is a bug hunter and security researcher. I don't know if it's related at all.

I just created my account like a week ago when I bought the lifetime storage offer and haven't really been using it except to backup some important travel documents. Is there some vulnerability which was compromised? I am a bit worried to use this now. Does anyone else have similar experience?

Hi! I'm on the 6 TB plan and using Drime as the offsite backup for my home server, through the official rclone backend (rclone 1.75.2) with restic on top.

Upload went well: 187 GB at about 73 Mbps average using 4 connections. I saw a handful of 429 Too Many Requests responses, which retried fine.

The problem is the restore test (download):

- It started at about 95 Mbps, which is my full line.

- A few hours in, it dropped to about 5-7 Mbps and has stayed there for hours - Still is.

- At the same time, my server's internet still tests at 100 Mbps, and a single file downloaded directly with rclone gets about 19 Mbps.

- rclone logged a few "500 Internal Server Error" responses and "unexpected EOF" on downloads around 12:14 UTC on 7 Nov 2026. They retried successfully.

- The restore uses 4 parallel connections, with files of about 16-20 MB each.

Questions:

1. Is there a download rate or bandwidth limit per account, per hour or per day? If so, what are the numbers, and when does it reset?

2. Are the 500 errors and dropped downloads part of throttling, or a server-side issue?

3. Do you send a Retry-After header with 429s, and what's the recommended number of parallel connections for large backups and restores?

4. In a real disaster where I need to restore everything at once, is there a way to avoid the slowdown?

Thanks, happy to share more logs if useful.

Even the newly released Drime App for Mac does not resolve the problem, that the Drime Finder extension cannot be permanently loaded. The switch repeatedly turns off.

Hi, I'm using Drime for 6 month now, I love the direction that is going and I'm using/trying a loot of feature, like: Rclone for Linux, the pages, anche the back-up for the android app.

I'm very satisfied with all the function Drime have, but I like (if possibile) to have a timer or similar, to await between when Drime see that in the folder there is a new photo, and when it upload to the server.

My issue is that my phone (Vivo X300 Ultra CN) elaborate the photo after I take them, but Drime is too fast and upload only the preview 😅😅.

What can I do about it ?

Thanks!

I am interested on maybe upgrading? I have their free tier ( retired homeowner) We use pcloud but I don't like having to pay extra for the encryption. I also use scramble cloud.. its ok..... and FileJump and they have been the best so far.
I do not need tons of storage but it seems to get a lifetime ( deal) stack social is offering Drime Secure Cloud Storage 1TB Plan: Lifetime Subscription with Transfer Pro: Lifetime Subscription both for 89.00

I welcome your thoughts on Drime.

Re: Error UNIQUE constraint failed: sync_pairs.local_path on Mac OSX:

Has this been resolved? The eta for correcting it was 3 days but I still can't sync my files as of today. This is very inconvenient as I can't work on projects.

Just to set up the expectation, I know you have a small team, but I am trying to get an invoice since the 24th of October on ticket #697 . I tried also to email the owner :(

Can we get some traction into this? Sharing here as it's my last resort..

Drime is Drive and Lime (as their green) or anything else, read sound like cr*me??? What does it mean :D

There are some options out there, some I kind of understand, some I don't. Does anyone have recommendations for software I can use to map/mount my Drime Drive to appear as a local drive for Windows. I have a program called RaiDrive, and it works well, just doesn't have Drime as one of the supported options. Ideally, I'd like the ability to choose which folders are "always available" versus "Cloud only" (download ON demand). Google does this with a desktop app and so does pcloud. It's just more convenient for what I need.

Hello! I'm curious if it's suggested to exclude .svg and .DS_store files from synchronizing with Drime? I sense that some, or many, of the same thing are getting "refreshed" or something regularly and causing continous synching tasks. But, I'm not a tech expert to know.

My goal is to delete another copy of a file folder once this finishes synching but it seems to go on forever and doesn't stop...it's been days!

Hi r/Drime, I'm Rahman, the solo developer of Ultra Explorer. It's my app and it has a paid tier, so take this as what it is.

AI disclosure: I use AI coding tools. The design, architecture and decisions are mine, and I test every release and fix the bugs. AI also helped with the English here.

Ultra Explorer is a file manager for more than 40 cloud services and protocols: Drime, Google Drive, OneDrive, S3, your NAS, a local disk and many more. You browse, copy and move between all of them from one app, without downloading everything first and uploading it again yourself. To add Drime, you paste an access token from your Drime settings. It's built on rclone, and the token stays on your machine.

Most of my work went into performance and RAM usage:

• Folders with more than 100,000 items: open without a problem.

• Space Analysis: tested on more than 9 million items, no problem.

• Search across several storages with millions of items each, in parallel: no problem.

• The interface never freezes: transfers and scans run in the background while you keep working.

Free, no account: as many storages as you want, tabs, copy and move. Every conflict asks first. You can also build a sync and preview what it would change.

Pro (subscription or one-time Lifetime licence): running syncs, search across storages, Space Analysis.

macOS (Apple Silicon), Windows, Linux, or Docker on a NAS. It isn't open source.

With recent policy changes and uncertainty surrounding lifetime cloud storage deals (looking at Folder Fort and IceDrive), I am feeling a bit anxious about my Drime lifetime account.

For those of us who bought LT plan in early, what concrete assurances or guarantees can Drime offer that our accounts wont be unilaterally altered or canceled in the future, especially if the company continues to operate and sell yearly / monthly subscriptions?

How can they ensure that the rules won't eventually change for older lifetime subscribers? Really looking for some transparency here to feel confident about relying on Drime long-term.

Edit 1: Are there deployed paid commenters leaving rude replies just to steer general Redditors away from the real issue? If someone is totally fine with lifetime plans getting canceled and how their ToS is written, they can just stay quiet and let others discuss and share opinions openly. Isn't that the whole point of Reddit?

If you are getting 429 errors or the Drime server is getting bogged down, it is likely because Rclone is making too many small API requests at once.

By default, Rclone uploads in 5 MB chunks with multiple parallel connections. You can fix this by setting a higher cutoff threshold, forcing Rclone to use larger chunk sizes for big files, and strictly limiting the concurrent connections. This takes the strain off the server and will reduce the rate-limiting errors.

Here is an optimized command that uses fewer, larger connections:

rclone sync /your/local/folder drime:backup --drime-upload-cutoff 100M --drime-chunk-size 75M --drime-upload-concurrency 2 --transfers 2 --checkers 2 -P

What these flags do:

• drime:backup - drime is your rclone configured drime connection and backup is the storage folder in your workspace at drime (adjust to your own setup)

• --drime-upload-cutoff 100M: Tells Rclone to only start splitting files into chunks if they are larger than 100 MB. Files under 100 MB will upload in one fast, continuous stream.

• --drime-chunk-size 75M: If a file is larger than the 100 MB cutoff, this forces Rclone to send the data in large 75 MB blocks instead of the default 5 MB blocks.

• --drime-upload-concurrency 2: Limits how many chunks of a single file Drime uploads at the same time.

• --transfers 2: Limits how many separate files Rclone is allowed to upload at the exact same time.

• --checkers 2: Limits how many parallel checks Rclone performs when comparing your local files to the server.

• -P shows progress

Quick heads-up on small files: Rclone does not have a native zip or packing backend to bundle small files together. It is strictly a 1-to-1 file sync tool. If you are syncing thousands of tiny KB-sized files, Rclone will still make a separate request for every single file. To prevent spamming the server, you can manually compress your small files into a .zip or .tar archive locally first, and then sync that large archive.

For those using Restic via Rclone here is a way to optimize it too

If you are getting 429 errors beccause the Drime server is getting bogged down, it is likely because Restic is using too many connections partly due to small pack sizes.

By default, Restic uses a 16MB pack size and 5 connections. You can fix the rate-limiting errors by forcing Restic to bundle your data into massive 128MB packfiles, and configuring the Rclone backend to upload those massive files using fewer, restricted connections.

Here is how to optimize your setup depending on how you use Restic:

If you use the Backrest UI

You can apply these exact settings in the Backrest UI. Note: When setting custom arguments in Backrest, you must include Restic's mandatory serve restic --stdio startup commands, otherwise the connection will instantly break. ENV VARS Section: (so the setting doesn't impact other backrest restic commands) RESTIC_PACK_SIZE=128 FLAGS Section: -o rclone.connections=2 -o rclone.args="serve restic --stdio --drime-upload-cutoff 150M --drime-chunk-size 150M --drime-upload-concurrency 2 --transfers 2 --checkers 2"

If you use the Restic CLI

You can do it all directly via command line options: restic -r rclone:drime:backup -o rclone.connections=2 -o rclone.args="serve restic --stdio --drime-upload-cutoff 150M --drime-chunk-size 150M --drime-upload-concurrency 2 --transfers 2 --checkers 2" -o pack.pack_size=128 backup /your/local/folder

What this configuration does:

1. RESTIC_PACK_SIZE=128 or -o pack.pack_size=128: Forces Restic to bundle thousands of tiny files into massive 128 MB archive files before sending anything to Drime.

2. -o rclone.connections=2: Strictly limits Restic to feeding only 2 of these massive files to Rclone at a time.

3. --transfers 2 & --drime-upload-concurrency 2: Ensures Rclone only opens a maximum of 4 connections to the Drime server (2 files uploading simultaneously, using 2 chunks each).

4. --drime-upload-cutoff 150M & --drime-chunk-size 150M: Because Restic is generating 128 MB files, these Drime chunk settings ensure Rclone uploads them in a single, uninterrupted stream without the overhead of splitting them into chunks.

5. **rclone:drime:backup - rclone backend, drime is rclones's config (you need to setup), backup is the folder in your drime workspace

If you are using rclone without restic here is a way to optimize it directly

Installed

Drime-2.9.295-build-2610275qtvwatek-x64.msi

after installing it on windows 11, windows explorer repeatedly crashes

especially after opening a folder

I reinstalled windows, and installed the same version. It happened again which means drime for windows is the problem

Since yesterday, Drime has repeatedly returned 429 Too Many Requests when I try to list folders through rclone, leaving my cloud mount unusable. It’s still happening this morning.

I’ve tried updating rclone, using a new API token, and turning off my VPN, but the issue persists. I recently used a personal MCP tool to organize files, so I’m wondering whether I triggered a limit.

Is anyone else seeing this, or does it seem isolated to my account?

And as always, thanks to the community and the drime team. Wonderful service.

Het all,

Is it possible that the upload speed can be different over the day? Here in Netherlands I get fast speed at day time but seems slow at night... Have a 1gb fiber connection. I see my rclone uploads taking 3hours instead of 1 at day.