Is it possible to keep dropbox device link static for each executed container ?

[testillano]

Hi,

Sorry if this is very inocent/basic question.

Everytime i run a dropbox container with this or similar images, this arises on terminal:

Please visit https://www.dropbox.com/cli_link_nonce?nonce=xxxxxxxxxxxxxxx to link this device.

This is normal, as expected, like when you run dropbox client on host. Same for docker compose deployments, because the container finally started is identified by dropbox engine like another new one, like a new device to be linked.

But, for "particular use" this is cumbersome (if it is not assumed to have always available/running containers) because you'll need to link the new device (container) in dropbox site (and probably you will have to unlink older ones). I mean, for use on-demand (i open my laptop and want to use this docker image to manage my dropbox accounts ...) it is a handicap ...

Is it any way to avoid renewing this, upon reboots ?. It depends on how dropbox calculates the link url to register/link the device (i didn't found the algorithm to try to understand/trick it). Perhaps this depends on the host id, mac, whatever and could be possible to "replace" or "supplant".

On summary, could it be possible to pin up this "link value" to identify new containers as the same device, furthermore, be taken into account for this docker image ?

Note: i tested with fixed hostname (by mean adding to docker run the option '-h hostname'), but same results. On Dropbox site it will appear as same device name, but actually a different link is needed to be reactivated ... :-(

thank u very much
BRs !

[otherguy]

Take a look at the README in my fork. You don't actually have to use my fork (you are welcome to do so of course) as it will work the same with @janeczku's fork.

Specifically the Persisting Data section.

[katzenbaer]

Take a look at the README in my fork. You don't actually have to use my fork (you are welcome to do so of course) as it will work the same with @janeczku's fork.

Specifically the Persisting Data section.

@otherguy Just wondering, how does your solve OP's problem? Is it because the DROPBOX_UID and DROPBOX_GID are used by the Dropbox backend to identify a unique link?

[otherguy]

@otherguy Just wondering, how does your solve OP's problem? Is it because the DROPBOX_UID and DROPBOX_GID are used by the Dropbox backend to identify a unique link?

No. Dropbox stores settings, authentication details etc. in a data folder. If you mount a local folder in its spot using Docker volumes, these settings are persisted on your computer. If you don’t, the settings are deleted once the Docker container is destroyed.

DROPBOX_UID and DROPBOX_GID are used to run Dropbox with the same user id that you use on your computer, preventing any file permission issues.