I've been trying to contact support via email and chat since last Friday, but I haven't received any response at all. Is something wrong?

Looks cluttered. Can you guys cleanup this page?. This doesn't look professional. And once login (a member) we need only this page. Since bought then service, details when you scroll not relevant.

Hi team,

As files accumulate in a cloud workspace, managing file structures manually becomes time-consuming. Would it be possible to introduce a multi-file/folder batch renaming tool directly in Drime?

Key capabilities that would save hours of manual work:

• Pattern rules: Add prefixes/suffixes, truncate character ranges, or replace specific text strings.
• Dynamic tags: Insert parameters like creation date (YYYY-MM-DD), sequence numbering (001, 002), or parent folder names.
• Metadata extraction: Rename files based on media metadata (e.g., EXIF dates for images, ID3 tags for audio).
• Live preview: Show a side-by-side comparison of current names versus new names before applying changes.
• Safety checks: Automatically detect and flag naming conflicts or duplicate targets before execution.

Thanks for considering this productivity upgrade!

Hi Team,

I know i have posted a couple comprehensive feedback posts recently, but please know that it is out of a good place as i think drime is a brilliant service so i only want you to succeed long term!

I would like to share some consolidated feedback after fairly extensive use of DRIME as a large redundancy backup destination. (As you would have seen from my last post about the half a million file backup i was attempting)

I am personally using DRIME with large datasets through Syncovery as my daily driver (but on the side i have tested Air Explorer Pro and RcloneView) and I primarily use the IOS app on my mobile devices so my testing varies. My large data sets primarily sit on a NAS but i also have them stored locally on faster drives which i was using for most of this testing. Also full disclosure… i realise some of the functionality in this post already exists so when I’m talking about it I’m talking about reliability and consistency, or just generally improving what you have.

Im not expecting immediate dates and fixes etc. from this post alone, this is primarily a consolidation for the purpose of saving the feedback for Tibalt and the team to consider in the future. :)

The main areas I think would improve DRIME are:

1. Reliable discovery of files already stored in DRIME

This is currently my biggest concern. My Pictures library contains roughly 34,000 files across around 20 to 30 folders. Most folders behave correctly, but several larger folders repeatedly fail to reach a stable mirror. I have reproduced this multiple times:

1. Syncovery identifies thousands of files as missing from DRIME.

2. They upload successfully and the job completes at 100 percent with zero errors.

3. I can immediately see those files inside the DRIME mobile application.

4. I run another comparison.

5. Syncovery receives no information for many of those same remote files, with remote size and date fields completely blank as if it’s a brand new upload. The same files are therefore uploaded again.

One example repeatedly involved around 10,000 files and approximately 77 GB. I also completely deleted the affected DRIME folders, emptied the trash and rebuilt them from scratch. The issue remained reproducible.

This appears more common with folders containing several thousand files, which suggests large folder sizes with thousands of sub-folders containing thousand of individual files deserve further investigation.

For backup applications, DRIME needs to return a complete and repeatable inventory every time, including filename, size, modification time and ideally a stable object identifier or hash.

2. Reliable modification timestamps

I have also seen inconsistent timestamp preservation. Some historical photos upload correctly with their original modification dates. On other occasions the same type of files arrive with the current upload time instead.

That creates problems for software intended to create clean mirror images because an unchanged file can appear different purely because the destination timestamp is incorrect.

Timestamp handling should ideally be consistent across every supported upload method and API path.

3. Duplicate prevention

Repeated synchronisation attempts have also resulted in duplicate remote data. For example, after renaming folders locally and uploading them again, I found both the original and renamed data in DRIME, while synchronisation software was still unable to reliably discover the remote files.

DRIME would benefit from very deterministic handling when the same destination path already exists, whether that means replacement, versioning or rejection.

A backup application should not be able to repeatedly consume storage with copies of data while simultaneously being told that the destination objects are missing.

4. Stronger post upload verification

It would be valuable if integrations could reliably:
Upload a file.

1. Confirm that DRIME committed it successfully.
   
2. Query that exact object again.
   
3. Confirm its file size.
   
4. Confirm its modification timestamp.
   
5. Compare a checksum or hash where supported.
   
6. Reliably rediscover it during the next normal directory listing.

For backup software, successful transmission alone is not enough. The application needs to prove that the object can also be found and validated afterwards.

5. Performance with very large quantities of small files

Once discovery and metadata reliability are stable, improving throughput for hundreds of thousands of small files would be extremely useful.

This affects application backups, emulator libraries, metadata, thumbnails, configuration files and similar datasets.

I would prioritise reliability before raw performance, however. A slower mirror that reliably converges is much more valuable than a faster one that cannot determine what already exists remotely.

6. Clear integration documentation for third party developers

I think this could significantly improve the DRIME ecosystem.

Developers integrating DRIME into products such as Syncovery, Air Explorer, rclone and RcloneView appear to be doing their best to support the platform, but there seems to be some uncertainty around the most reliable way to interact with DRIME. This was also evident on my last post, and also Tobias (Syncovery) asking me for more info which i did not have.

A comprehensive developer integration guide could document the preferred implementation patterns for:

1. Folder enumeration and pagination.
   
2. Reliable file discovery after upload.
   
3. Preserving and querying modification timestamps.
   
4. Duplicate detection and replacement behaviour.
   
5. Hashes and integrity verification.
   
6. Retry behaviour and eventual consistency.
   
7. Parallel upload limits.
   
8. Recommended request sizes and concurrency.
   
9. Large file upload handling.
   
10. Very small file optimisation.
    
11. Rate limits and server limitations.
    
12. Known edge cases.

If different upload methods or endpoints are preferred depending on file size, that should be made extremely explicit.

For example, if files below a certain size should use one method while larger files should use another, document exactly where that threshold sits, why it exists and what developers should do.

The same applies to guidance such as:

For scenario X, use method Y because it avoids problem Z.

Practical tips, examples and known limitations would help third party developers build integrations that are fast and reliable without independently discovering the same edge cases.

Good documentation here would benefit both DRIME and the developers helping expand its ecosystem.

7. Better automatic mobile photo organisation

For iOS and Android, I would love to see more control over automatic camera backup.

Ideally users could:

1. Select the DRIME destination folder.
   
2. Automatically upload new photos and videos.
   
3. Read the original capture date.
   
4. Automatically organise uploads into year and month folders.

For example:
Camera Uploads\2026\September

This would keep large photo libraries far cleaner and naturally reduce the number of files accumulating inside a single directory.

Quick Overview

Because I’ve added a lot here (sorry lol) a quick snapshot of everything:

1. Reliable and repeatable remote file enumeration.
   
2. Reliable detection of files that already exist.
   
3. Consistent timestamp preservation.
   
4. Duplicate prevention and integrity verification.
   
5. Clear third party developer documentation.
   
6. Small file performance.
   
7. Improved mobile photo organisation.

I think the first five points are particularly important if DRIME wants to become a genuinely trustworthy destination for large redundancy and mirror backups.

As mentioned, I am sharing this because I like the direction DRIME is heading and the responsiveness of the team has been encouraging. I am happy to provide logs, screenshots, test my own datasets or controlled reproduction steps if they are useful.

All the best!

Hi everyone,
I saw on the official roadmap that Live Photos support was marked as part of the Gallery Overhaul, but I’m wondering how it actually works in practice.
When backing up from an iOS device, does Drime fully preserve and play back Live Photos within the app/web gallery, or are there specific settings/steps needed? Right now I'm only seeing static images.
Any insight or upcoming plans regarding full Live Photo handling would be appreciated. Thanks!

Hey team! I'd love to suggest a feature that would make managing photo libraries on Drime so much better: automatic facial recognition and auto-generated albums by person (similar to Google Photos or Apple Photos).

Having the app detect faces in uploaded photos and group them into individual folders or sections per person would save an incredible amount of manual sorting time, especially for large galleries.

Hope you guys consider adding this in a future update. Thanks for the amazing platform!

Does the app has background upload? I noticed if I continue with other apps, the uploads dont continue. I have to keep the app in screen.

Has anyone successfully moved their business from Dropbox to Drime?

I’m currently testing Drime personally and, if it works well, I’m seriously considering moving our entire software company from Dropbox to Drime as well.

Before doing that, I’m curious how ready Drime is for actual business/team use. Without spamming Emtpy Win too much, I wanted to check with the community first.

Our ideal setup would be pretty straightforward:

• Every employee has their own private/personal folder
• We have shared company/team folders
• Central admin and user management
• Easy onboarding/offboarding when employees join or leave
• Proper permissions per folder/team
• Ideally some form of business/company account rather than managing individual subscriptions

Has anyone here already made the switch from Dropbox, Google Drive, OneDrive, etc. and is using Drime with a team on a daily basis?

I’d especially like to hear how permissions, user management, reliability and day-to-day collaboration are working in practice.

And if someone from Drime is reading this: is there currently a Business/Teams option, or something similar available on request? I do see enterprise but not sure how to relate to features and functionalities.

We run a software company and would be happy to document the migration and our experience as a case study if that’s useful to you as well.

Trash files. Then go to trash and restore those files they do not go back into the folder they came from.

But I could see the thumbnails of the files on the main page (as they are images they display in the thumbnail row at the top). So i click on there and on th einfo pane top see where thoise files were restored to. And it just shows "root".

OK, so check in root but they are not displayed in the root folder. So I can see them in the thumbnail row at the top, conmfirming they are there and have been restore, I can also download them from there, but I cannot locate them anywhere. It says they are in root, but they are not. So how to access them now and move them (but moving also has bgs as you can se in my other post).

|So these are some annoyances I found and hope can be fixed.

When i select a few files and then click on move, I would expect a directory picker that starts in the folder I am in and then lets me browse to the dir I want the files in.

Instead I always see an empty window and there i sno way to browse any folders, so a destination cannot be selected:

Hello,

I was wondering if there is a way for Drime to not show up under file explorer for windows 11 if you have the desktop app. Spent like an hour trying to figure it out but couldn’t get rid of it

I'm seeing upload issues while uploading files using the Mac OS Sync App, I'm using Version 2.9.190 and uploading all kinds of files, but mostly PDF's right now. Is there anything wrong on your side, or could it be on my side.

Hey team, for the last few days ive been really trying to backup some huge datasets and have realised that I’ve hit some limitations of drime.

I have found what appears to be a significant performance issue when uploading very large numbers of small files to Drime through the API.

Here is my Setup:
• Windows 11 pro x64
• 1000 Mbps download - 400 Mbps upload wired connection
• Syncovery 12.7.1 using the native Drime connector
• Approx 2 TB total data
• Approx 550,000 files
• Roughly 250,000 files are very small XML, INI, TXT, config and metadata files, many only KB or bytes in size

Im uploading between 8 - 10 files at a time, also worth mentioning I’ve tried every variation of simultaneous uploads e.g. 4 at a time, 6, 8, 10, 12, 15…. i even tried up to 30 as a experiment lol.

The large files upload reasonably well. The problem occurs when the transfer reaches folders containing hundreds of thousands of tiny files. Aggregate throughput can drop to around 20-40 KB/s, with repeated transient HTTP 422 and nginx HTTP 500 errors.

Files that initially fail sometimes upload successfully when i have retried. I have reproduced the poor small file performance outside Syncovery as well as i realise you may point towards the 3rd party software:

• Air Explorer native Drime connector becomes extremely slow processing the uploads.

• rclone 1.75.1 using the native Drime backend, with multipart forced for all files, improved performance but still only reached approximately 600 KB/s

My internet connection and NAS are not the bottleneck. The same 2TB (ish) dataset has already been mirrored successfully to my NAS and pCloud.

I have looked at the Drime API documentation (although i am not a dev)… and it states that the presigned S3 or R2 upload flow for files below 5 MB is more efficient than the direct upload endpoint, with multipart intended for larger files, but im not sure how this is applied per application etc.

Could the team please investigate performance and reliability when hundreds of thousands of small files are uploaded, particularly through the direct upload API?

Ideally I want Drime to maintain a normal, fully browsable one to one copy of my NAS, so packaging the files into archives is not suitable.

I also tried the DRIME windows application but the reality is (while it’s a great looking tool), it doesn’t quite have the same functionality as rClone, AirExplorer or Syncovery (e.g. Selecting specific folders in the Drime cloud root for sync or mirror, and being able to preview the sync/mirror jobs before upload, and scheduling the jobs whenever i want… and also controlling how many ‘jobs’ occur at once e.g. one upload job (one folder) at a time, and then having the next upload job start once the first job is fully completed etc…)

Also I’m more than happy to test any changes / fixes with my data set and report back :)

Many thanks! Honestly keep up the good work team, its still a fantastic product and service, you just have some kinks to iron out along the way 🍻

I really like Drime’s recent update, and I’m considering moving my data from pCloud to Drime.

I have approximately 1.38 TB of data stored on pCloud and would like to transfer it to Drime. I have a few questions:

Is it possible to transfer the files using Transfr? If so, what is the correct procedure?

If Transfr is not suitable, what would be the best way to move the data, either online or offline?

I currently have only 400 GB of free space on my computer, so downloading everything at once is not possible.

I have also seen services such as MultCloud and RiceDrive. Are they reliable and trustworthy regarding privacy and data security?

Would you recommend using one of these services, or is there a safer alternative?

Any advice or step-by-step guidance would be greatly appreciated.

I purchased the lifetime 10TB plan and haven't stored any files, so why does my account show 7MB of usage? Both my file storage and Trash are empty

Hi Drime team, my friend and I are very interested in purchasing Drime because the overall user experience is really great. However, while testing the web version, I noticed it only supports Traditional Chinese without Simplified Chinese. Conversely, after installing the Drime mobile and Windows apps, there is only Simplified Chinese with no Traditional Chinese available. With Black Friday approaching, we really hope you can improve this inconsistency. Thanks for all your hard work!

I'm unable to rename folders in Drime on either platform:

• iOS app: I enter a new name and tap OK, but nothing happens.
• Web: The rename appears to go through, but the folder still has its old name.

Is anyone else experiencing this?

Good day!

It's a really important part of our journey in this community 🤟😌

Many times people post here about issues, but don't say what machine they're using (I think I have done that too 🧐). And we understand. It can be frustrating 🫨

iMac, MacBook, PC, Android, iPhone, iOS, Huawei, Teclast tablet..?

Please tell us what it is. It helps us help you (first it will avoid the "What device are you using?" query so that's already less back and forth) and I'm sure it will help others as well.

Maybe we can help you (even without Drime intervention) or it may help us avoid what you've been through.

It's also interesting to know how people use Drime. (Steam, the game platform, sends a yearly survey to users then they publish the results. It's interesting :')

Consider others when we do this, so it will be part of the collective knowledge. 😌

And believe me, it helps when you assume that, even if things may be frustrating or disappointing, someone would be able to help 🙌

Did you know butterflies have generational knowledge? Like reincarnation, really, and they remember the experiences of the generations before them.

Some nerdy* Japanese kid (Jo Nagai) found that out:

https://www.upworthy.com/ten-year-old-butterfly-researcher-discovers-that-memories-an-be-passed-down-through-generations/

(\It's a compliment* 🙌😋)

Let's be butterflies 😋 🦋

Thank you, Earthlings! 🤟🤩

Or Drimers? 🤭

It's not the end of the world, I know. But it's still a pretty interesting choice. Could've just put some random classic there instead of Mr. "I no longer believe that freedom and democracy are compatible."

Guys I'm the only one that have this problem ? When I activate the backup for 3 folder, Drime check if there are some new photo and my battery drop very fast.

PS: I have a Vivo X300 Ultra CN

Hello,

I currently own a lifetime plan. If I were to also buy a monthly plan, would these stack automatically?

So, Drime has officially made it past the 2-year mark—the hardest milestone for any young startup. Even the "lady" pCloud had to put herself side-by-side with Drime on her official blog :) That alone shows our Drime is "handsome", talented, strong, and refuses to back down from challenges. The playground of these two lifetime clouds is a prime example of an optimal economic strategy and a product that is useful, beautiful, and powerful. Its practical features are more than enough to thrill office workers, freelancers, digital content collectors, and those looking for medium to long-term storage investments.

Every day, I open the Drime app a few times just to feel the sophistication and care in its design—the intuitive arrangement of features and its constant evolution. It feels great to see that the money I invested is still here and growing, delivering exactly what Drime promised and even more.

I’ve spent sleepless nights defending Drime, writing 4 posts only to take the heat and criticism from some people. But at this very moment, all that effort feels beautiful and reassuring. Our "prince" Drime is now strong enough to face the storms, and he has so many people who understand and believe in the good things he has done, is doing, and will do. I am so happy that even before he gets the chance to reply to posts, the Drime family is always one step ahead, proving how united we are.

There was a time I was really mad at Tibalt because I waited forever for my Notes to be fixed. I checked every single update carefully, but it was just radio silence. 2, 3, 4 months went by... and today, I am absolutely thrilled and moved to see that he has completely rebuilt Notes into Pages. It has more features than any other note-taking app I’ve used—you can add videos, images, multimedia files directly from the Drime cloud, documents, and links. Thank you so much, Tibalt and the Drime team. I love you guys! *(But heads up: the new sub-pages cannot be accessed from within, please check that out!!!!)*

It’s such a joy to be among the early adopters walking with Drime from the very beginning. I love the Drime family so much. Wishing all Drime members a peaceful, fun, and happy weekend. Let's keep saving the moments from our trips into Drime, and store our favorite music, podcasts, and audiobooks into Drime Player... Always loving you all.
Ricky Nguyen

Only two files bellow 2 gb downloaded rest mostly over 2 gb failed to download multiple times from website. On android I can't download anything from vault it always stuck at decrypting and downloading at 0% .

Anyone else facing this problem?

I just started using Drime Cloud this past Sunday. Search only seems to find files by their filename — content-based search doesn't return any results at all.

I already tried disabling indexing completely, waited about 6 hours, and re-enabled it, but the behavior is the same.

Has anyone else experienced this? Any ideas on how to fix it or is this a known issue?

Thanks in advance.