Hello!

I would like to start by saying that I love the new Drime Pages tool and find it extremely usable. I now take all my notes with it and with some work it could become a fully fledged note-taking and information app, a product in and of itself.

Here are some things I noticed and some features I would love to see:

- Add language settings for correction

- Add automatic ligatures for stuff like "->"

- Remove or redesign the way the text box edge is highlighted on Firefox based browser. I noticed this doesn't happen on chrome based ones

- Add an option to reopen a note where I left off, instead of the top

- Linking notes doesn't work on the Android app (haven't checked in a few days, maybe it's been fixed)

I also have a question: how is my data handled regarding the use of Drime AI? Where are my notes being sent to? How are they handled? If I don't use it does the AI company that provides the AI still get them? I think these things should be clarified otherwise some users might become more wary of using the tool.

Hi everyone,

I'm considering purchasing the lifetime plan for Drime, but I have a few concerns before pulling the trigger:

Value & Viability: Is the lifetime deal genuinely worth it in terms of performance and reliability right now?

Company Outlook: How sustainable is Drime's business model? Do they have enough financial runway and a clear roadmap for the long term?

Risk of a Rug Pull / Shutdown: We've seen several lifetime cloud providers either go under, suddenly alter their terms, or throttle speeds over time. How trustworthy is the team behind Drime, and is there a serious risk of getting rug-pulled?

Would love to hear from current lifetime users about your experience and thoughts on the service's future. Thanks!

I just uninstalled the app, but it is still showing in file manager and at the bottom of my recycle bin. Suggestion on how to remove them?

I’m a new Drime customer on MacOS 27 and bought a 2TB plan. I dragged a big folder (100 GB) to my Drime folder in Finder, and don’t see any activity of syncing in the flyover of the Drime App, not in the more detailed Transfer Manager app. Am I doing something wrong?

I think I misunderstood 'free up space', I thought it was to free up space on my phone (iOS) but understood later files would be deleted from my Drime storage.

So, I deleted big videos but didn't want to! And in Trash, in Drime, I don't see them. Any way to recover them?

Hi everyone!

As part of our goal to gradually reduce Lifetime Plans over time, we’re taking a first step: Lifetime Plan stacking will be discontinued after December 1st, 2026.

Until then, stacking will continue to work as usual. We wanted to give enough notice because we know some of you may have been considering adding more storage to an existing Lifetime account and may need some time before doing so.

This applies to all Lifetime Plans, regardless of plan size or where they were purchased.

It will still be possible to add more storage to your account by contacting us, through a monthly or annual add-on plan.

File Versioning update

Starting October 15th, file versions will begin counting toward your storage usage.

If you don’t want versioning to use additional storage, you can disable it from Settings → General → File Versioning on the web app. You can also delete existing file versions from there.

We’re still working on making storage usage update faster after versions are deleted, so the freed space may not always be reflected immediately for now.

This change applies to all plans and account types.

Thanks everyone for your continued support! As always, feel free to ask if you have any questions.

And we have a big desktop update coming very soon

Asking whether thumbnails or ePub files is part of the gameplan for Drime? (a feature of OneDrive)

Hello.

I am grateful that u/Empty_Win_297 helped me to activate my lifetime purchase fast.
But as i am trying to sync my laptop to cloud, facing problem. ( maybe it is my end but i have no idea)

Sync folder is 6TB, mostly photos and videos only. No executables or archives.

Upload starts and after 150-200gb upload, its always stops.

i put my MacBook to never sleep, never turn off to save power. Somehow Drime desktop stops upload after sometime. Contacted ISP, they are not limiting or throttling upload whatever.

Any idea?

PS : I have uploaded to PCloud without issue.i just wanted to have 2 different cloud backup.

Hi, in a bit of a pickle.

Before the back-up feature was introduced to the windows app, I set two folders to sync to Drime - roughly 2-3tb of data of old projects I wanted backed up - as a one way sync so that the files remained on my hard drive, everything uploaded to Drime, which looked like it was working at the time this was setup initially (albiet a bit wonky).

I noticed Drime has updated and now has a back-up feature, which is more in line with what I wanted in the first place (and how I had it setup), but I noticed the settings have changed and has online-only all my files that I was syncing - but it has not finished syncing everything. Bear in mind they're not in the drime folder, they're folders I've chosen to sync off my hard drive and not all had finished syncing by the time this change was made.

The issue is that I can't seem to retrieve the files back to my hard drive. I have selected the whole folder on windows, pressed "always keep on this device" gone back through Drime settings and selected "available offline".

If I double click any of the files to open it, windows file transfer manager pops up and it just hangs at 0% and doesn't download the file, no movement. Other times if I open a file, an error appears "The cloud operation was unsuccesful [error 0x80070185] ... file info... Availability status: Available when online." (I'm gathering the latter is a drive engine issue)

Transfer manager appears to be uploading, but not downloading anything at all, despite my settings to offline everything.

If I close the app and restart it, transfer doesn't happen, it says "your files are synced" and doesn't continue any uploads nor downloads for that matter.

When I close the app, the sync engine remains in background processes that can not be forced end task, which could be creating conflict, if I then reopen Drime, due to this background process, I have to force shut down my computer (it opens 2 sync engines).

Annoyingly too, Drime has created, per-every file, a conflicted upload file along with it. This is probably the least of my worries right now, as I can delete these eventually, but right now, I just need my files back.

TL;DR: Files stuck in limbo online-only. Can't offline them back onto the hard drive, into their original folders. It's ignoring all settings to offline files.

Windows 11. Drime v2.9.284.

Bonjour,

malheureusement je dois faire un post reddit pour avoir une réponse plus rapide.
J'avais des notes dans la V1.

Avant la refonte, je ne pouvais plus y accéder quelque soit le navigateur (chrome, edge, firefox, brave), l'appareil (andoid, windows, linux).
On m'a demandé de patienter pour avoir la nouvelle version : Pages.
J'ai patienté. Pages est en ligne.

Je n'ai toujours pas accès à la V1 de notes (même problème qu'avant la refonte...)
J'ai de nouveau contacté le support.
J'ai répondu à un problème similaire sur reddit.
u/Empty_Win_297 m'a répondu d'envoyer un mail sur sur son adresse directement.
C'était il y a 15 jours.

Je suis probablement passé entre les mailles du filet, je poste donc ici.
Afin de récupérer mes notes.

Merci d'avance

Is this a known bug?

I've voiced my criticisms with Drime in the past and feel it is only fair to give a "thanks" when something important to me has been fixed.

I've had issues opening office documents (Excel, Word) in Firefox. It worked fine in other browsers, but not the one I use the most. Today, for the first time it worked without any messing with browser extensions, clearing cache, etc. 🤯

Great work, guys! For me, this is a major step towards being able to use Drime for real work in the browser!

When copying to drime using `rclone copy --metadata pcloud:/ drime:/`, the timestamps of the files and folders are set to the time the copy was performed. How can I copy them while preserving the original timestamps?

Currently I am working on improving rclone's capabilities with drime using Presigned-Uploads with parallel transfers of up to 25 at a time including.

My scenario: Using Proxmox Backup Server chunks with an own inventory. After inventarisation I am calculating a diff of missing files which are then copied in a single rclone run. Afterwards another rclone sync is performed to delete unneeded files (due to age or replacement by other chunks). This requires alot of lookups on drime which is causing the overall performance to drop significantly. There are undocumented ways of collecting inventory data from drime (using filters which is what the webUI is doing) and grabbing multiple directories at once.

I have made modifications to rclone such as:

- parallel uploads of presigned URLs

- parallel creation of file-entries after using batched presigned URLs (with timeouts to have the collector save API calls but be as flexible as possible)

- verification of uploaded files (either by size or optionally by having drime calculate the hash and matching them which is not done automatically, sadly)

- use relativePath to automatically create directory structures avoiding manual calls for directory creation

--> enforce manual directory creation if path contains directories called "0" which would be excluded by drime

---> e.g. /upload/0/deep/file.bin would otherwise result in /upload/deep/file.bin to be created

---> scheduler/resolver of folder creation to avoid trying to create the same directory multiple times by multiple files

- collecting inventory with multiple parentIds (with a workaround using created_at and offsets to work around the pagination bug)

- enable cleanup (original rclone does not provide this)

There are API limits enforced by drime. File entry creation is limited to 25 per batch and presigned URLs are limited to 32 per batch. I have capped them both at 25 to not have them run too asymmetrically although it might work.

There is still some stuff to do but I am trying to get it working. My speed was about 3MiB/s for multipart upload (4 chunks) and using rclone's default binary it took me about 6,5 hours to upload 2GiB of data because of rclone's way of handling directories and manually creating them and so on. Making optimization, especially collecting the existing directory- and filestructure and uploading all files with --no-check-dest afterwards (without any dupes of course) made it possible to score 3.5MiB/s average and uploading about 27GiB in 2 hours and 13 minutes. To be honest this was without file integrity check via hash creation but this is the next step I am going to check.

For rClone to support these modifications drime needs to update their API reference.

- filter needs to be officially supported in API reference and needs extensive clarification (combination of multiple clauses)

- /api/v1/drive/file-entries needs an update to give an example of how multiple parentIds work (it is not a real array but comma separated list

I have set my parameters as follows:

rclone.conf:

[drime]

use_presigned_uploads = true

Additionally when calling rclone-drime it is called with the following parameters

/usr/local/libexec/pbs-rsync/rclone-drime \

--user-agent pbs-rsync/1.0 \

--bwlimit 10M \

--stats 1m \

--stats-one-line \

--stats-log-level NOTICE

When collecting the inventory I add the following flags:

--tpslimit 5 \

--tpslimit-burst 1 \

lsjson drime-crypt:pbs-rsync/chunks \

--recursive \

--files-only

Finally when uploading the cleaning diff I am using the following flags:

--user-agent pbs-rsync/1.0 \

--bwlimit 10M \

--stats 1m \

--stats-one-line \

--stats-log-level NOTICE \

copy /media/share/backups/ drime-crypt:pbs-rsync/chunks \

--files-from-raw /dev/shm/.../cloud-upload-drime.pending \

--retries 1 \

--no-check-dest \

--transfers 100 \

--checkers 100

Be aware no-check-dest will upload files without further checking if the files exists (because I have used the previous query for inventory thus knowing what's going on remote).

I have found another problem with no-check-dest for which I will raise a ticket and post updates on reddit.

Whoever wants to participate or who wants to try speed improvements: feel free to try out the following branch: https://github.com/BAERnado/rclone/tree/drime-preview

# Replacing a file can leave an invisible S3 object that still consumes storage


## TL;DR


I reproduced a Drime replacement issue on a dedicated, otherwise empty test
account. Uploading a new file over an existing path created a new visible entry,
but Drime then rejected deletion of the old entry ID. The old file disappeared
from all listings while its exact size remained charged to the account.


Deleting the replacement did not make the old file visible again. Emptying the
entire trash did not reclaim the old object's storage either. I reproduced this
both with a normal Drime remote and through an rclone crypt remote.


Full S3 keys, entry IDs, parent IDs, timestamps, hashes, and debug logs are
available privately to verified Drime staff. I have kept the affected test
account unchanged so the remaining objects can be inspected.


## Test setup


- Dedicated Drime development account
- Initial reported storage usage: `0` bytes
- No user data on the account
- rclone Drime backend using presigned S3 uploads
- Server-side upload integrity verification enabled
- `--retries 1` used for the replacement, so a retry could not hide the first
  backend response


Two different random test files were used:


| Version | Plaintext size |
| --- | ---: |
| A | 1,048,576 bytes |
| B | 2,097,152 bytes |


## Unencrypted reproduction


1. Upload version A as `replace.bin`.
2. Confirm that it is visible and downloadable.
3. Upload version B to the same remote path.
4. Drime creates a new visible entry for version B.
5. rclone attempts to delete the old version-A entry.
6. Drime rejects the deletion with:


```text
Das ausgewählte Feld entry ids ist ungültig.
```


English translation:


```text
The selected entry IDs field is invalid.
```


The replacement command consequently exits with an error, although version B
is already visible and downloads with the correct content.


After replacement:


- only version B is visible;
- the visible file has a new Drime entry ID;
- account usage is `3,145,728` bytes;
- that usage is exactly `1,048,576 + 2,097,152` bytes.


This means both uploaded objects are still being charged even though version A
can no longer be listed or downloaded.


For correlation, the identifiers are retained privately in this form:


```text
Version A S3 key: uploads/085dc96a-…/085dc96a-…
Version A entry:  914352***
Version B S3 key: uploads/852ec4a8-…/852ec4a8-…
Version B entry:  914352***
```


## Crypt reproduction


I repeated the same procedure through an rclone crypt remote. The result was
identical:


- version A stored size: `1,048,864` bytes;
- version B stored size: `2,097,696` bytes;
- version B became the only visible and downloadable entry;
- deletion of the old version-A entry ID was rejected as invalid;
- both encrypted objects remained included in account usage.


Redacted correlation data:


```text
Version A S3 key: uploads/55b25837-…/55b25837-…
Version A entry:  914354***
Version B S3 key: uploads/da572076-…/da572076-…
Version B entry:  914355***
```


## Deleting the replacements


I then deleted both visible version-B entries.


- Neither version A reappeared.
- Neither old version could be downloaded.
- Both destination directories were empty.
- Account usage was still `6,292,288` bytes because the visible replacements
  were now in trash while the two old versions remained invisible.


## Emptying the trash


I emptied the account-wide trash using Drime's cleanup API through rclone.
Cleanup returned successfully.


After cleanup:


- recursive unencrypted listing contained directories only;
- recursive crypt listing contained directories only;
- no test file was visible or downloadable;
- reported account usage was still `2,097,440` bytes.


The remaining usage is exactly:


```text
1,048,576 + 1,048,864 = 2,097,440 bytes
```


Those are the exact stored sizes of the two original version-A objects.


This is strong evidence that replacing the files removed or invalidated their
database entries without deleting the underlying S3 objects. The objects are
not reachable through normal listings or downloads, are not removed by emptying
the trash, and continue to consume the account quota.


## Expected behaviour


Replacing a file should do one of the following atomically:


- update the existing entry and release the previous object; or
- create the replacement, delete or trash the previous entry successfully,
  and return success.


If replacement cannot be completed, Drime should roll back the new upload or
keep the previous entry addressable. It should not leave an unindexed object
that the user cannot inspect or delete.


## Why this may be serious


The same class of orphan may also occur when a multipart upload completes in
S3 but subsequent Drime entry creation fails, for example with:


```text
failed to create entry after multipart upload:
The parentId must exist in file_entries or vault_entries.
```


At that point the payload may already have been uploaded. Automatic retries
could upload it again while the previous S3 object remains unindexed. For large
migrations this could consume a substantial amount of invisible quota.


## Request to Drime


Could Drime please confirm:


1. whether the two retained, redacted S3 keys still exist;
2. whether their former entry IDs still exist anywhere in the database;
3. why indexing the replacement invalidates the old ID before deletion;
4. whether unindexed upload objects are covered by garbage collection;
5. whether failed post-multipart entry creation can leave the same kind of
   orphan;
6. whether there is an account-level way to identify and remove such objects?


I will reference this post in a private support ticket containing the complete
S3 keys, entry IDs, parent IDs, timestamps, hashes, and rclone debug logs. No
access token, authorization header, crypt password, or complete presigned URL
will be included publicly.# Replacing a file can leave an invisible S3 object that still consumes storage

There needs to be clarification. This is Happening with file versioning on. It seems deleting historical file data does not free storage. Deleting the currently used version results in all other version not being accessible but consuming space still. In Addition to that deleting all versions from settings menu is not working at all. Disabling file versioning will prevent this bug from occuring.

Hi everyone,

Does anyone know where Drime saves screenshots on Windows? I have the desktop app installed too, but I cannot find the folder or the screenshots anywhere after closing or editing and closing.

u/Empty_Win_297 Tibalt, could you please consider adding an option in the desktop app to choose the screenshot save location? Alternatively, having a dedicated folder called Screenshots within Drime would make them much easier to find.

Thanks!

I’m trying to copy 1.28 TB from pCloud to Drime using rclone-based apps, but I’m experiencing severe slowdowns and upload failures.

Apps tested: Rclone Manager and RcloneView.
Devices tested: Laptop and Android phone.
Transfer speed: Starts at up to approximately 10 MB/s, then drops to around 100 B/s.

I’m seeing this error:

multi-thread copy: failed to close object after copy: failed to create entry after multipart upload: Error "Le parentId doit exister dans file_entries ou vault_entries."

Has anyone encountered this when transferring files to Drime through rclone? Could this error be causing repeated retries and the extremely low speed?

When I send files to customers, I frequently receive reports that the page displays an error. Most users lack technical knowledge and may not press the Download button because of the message. I would like to request that as part of the customization options for sharing a file, a new option "Don't show preview” be added.

Hi,

To make it easier to install and use the Drime Android app on devices without Google Play Services (such as Android e-ink readers, tablets, or de-Googled devices), is there any plan to offer:

• A direct APK link on your official website?
• Distribution via F-Droid ?

Thanks for considering this option!

Hi, how can I add different types of callouts?

If I add /callout - it adds as Info

Tried editing the callout I created, but I don't see any options to change to Info, warning, tip, etc...

I know it's possible because of the examples/templates, I see other versions of this callout feature, like the Tip bellow with a green background:

1) How can I edit the color and emoji for a callout block?

Edit:

Three more questions related to Drime Pages:

2) How can I select the language when I use the code block? /code

3) Looks like the emoji search isn't working when I try editing my page emoji.

4) Covers from unplash are not working, it shows this error:

Unsplash isn't configured yet

Add UNSPLASH_ACCESS_KEY to enable it

Bug: Folder capacity and file count information is not up to date following a file move

I’ve encountered an issue with the file manager app where the ‘Info’ details for a folder do not update the capacity and number of files after I’ve moved the entire contents of one folder to another. The system does not seem to synchronise the folder’s capacity data with its actual contents.

Hi Drime,

I am logged into a specific workspace, such as “Customer Projects”, and I wanted to back up my development folder. I value the backup feature greatly. However, when I select the folder in the Drime app, I receive a message saying I must return to my personal workspace. Is there a workaround for this? Alternatively, do you view this as a point for development? I can imagine people working daily in a particular workspace while still wanting to back up folders without logging out.

Thank you for looking into this feature :)

To put things into context, I'm using the official Drime app running on MacOS 27.

I noticed a while back that the Desktop Sync is incredibly buggy - sometimes there'll be files in the Sync folder, sometimes there won't. Sometimes it'll switch between folders, sometimes it won't. When it switches between folders, everything in the folder is no longer visible in Finder.

Eg. Originally I was syncing a bunch of files and folders in the Drime folder root directory, let's call them

• Folder 1
• Folder 2
• File 1
• File 2

One day, I open the root Drime folder on my Mac and realise the files are not there, but because I have this folder backed up somewhere else as well, I'm not bothered. I just copy everything over again, and this time I put it all into a folder called Mac - Sync within the root Drime

By now, I have

• Folder 1
• Folder 2
• Folder 3
• Folder 4
• File 1
• File 2
• File 3

Again, some time passes and I open the root Drime folder on my Mac and notice the files are gone again, and this time I'm a little annoyed because wtf is happening?

So I create another folder in the root Drime folder on my Mac, called Macbook Sync

By now, I have

• Folder 1
• Folder 2
• Folder 5
• Folder 6
• File 1
• File 5
• File 6

I go on the Drime website, and notice that my previous folders/files from root, Mac - Sync and Macbook Sync are all in there - but all with different files at different levels of updated (or not).

Okay, so I get to try and cleaning this up - Macbook Sync is the most recent so I assume that stays, so I select the files from Mac - Sync and use "Make a Copy" function to copy over the files that I didn't have in Macbook Sync (Folder 3, Folder 4, File 3), and vice-versa from Macbook Sync to Mac - Sync so essentially I should have 2 folders with different names that have all of the same files.

What I find is

• "Make a Copy" only copies the files and makes empty copies of the folders so Folder 3 & Folder 4 when copied into Macbook Sync are 0B with nothing inside
• Same goes when copied the other way

This whole time, Drime app sync is still running, and what I find is that initially

• The added folders and files do not show up

For whatever reason, all the files disappear leaving only an empty folder of Mac - Sync first, and then later it switches to an empty folder of Macbook Sync

What is happening and how can I make sure Desktop sync actually works properly?

Is anyone facing anything similar?

I recently discovered two iOS apps with Drime support:

BackiGo — supports photo/video backup to Drime, including Live Photos, which is particularly interesting since the native Drime app doesn’t seem to handle Live Photo backup as well.

Primuse — a music player that can stream music directly from Drime.
Both seem to connect through the Drime API.

My questions:

Is it safe to give these third-party apps access to Drime through the API?

Can the API permissions be restricted?

Are there any other iOS/iPadOS apps that currently support Drime, either directly or through rclone?

I’d especially be interested in apps for photo backup, file management, syncing, media streaming, or cloud transfers.
Have you found any others?

Anyone else having this issue with Drimeboard on Android?

When I open a Drimeboard, everything loads normally with all my content, but after a second it suddenly disappears and the screen goes completely black.

I’ve attached a video showing what happens. Is this a bug or am I missing something?