[SUPPORT] dropbox reports "Connecting..." status forever
the-wes opened this issue · comments
I am not sure if this is a bug, so I'm starting it as a support request first. This is on a centos 7 system. Here is the output of inspect:
# docker inspect dropbox
[
{
"Id": "bf6d4e0909541c3cf4d9c24ef4f61561873ea59e33f1aa54ba198d5ce3519c4c",
"Created": "2021-08-13T22:25:23.60815582Z",
"Path": "/docker-entrypoint.sh",
"Args": [
"/opt/dropbox/bin/dropboxd"
],
"State": {
"Status": "exited",
"Running": false,
"Paused": false,
"Restarting": false,
"OOMKilled": false,
"Dead": false,
"Pid": 0,
"ExitCode": 137,
"Error": "",
"StartedAt": "2021-08-14T22:39:42.5030515Z",
"FinishedAt": "2021-08-14T22:48:33.390501045Z"
},
"Image": "sha256:096b2cd20f54ff10f15af6564f599f4f6458542fba733e852df521f9bb28711d",
"ResolvConfPath": "/var/lib/docker/containers/bf6d4e0909541c3cf4d9c24ef4f61561873ea59e33f1aa54ba198d5ce3519c4c/resolv.conf",
"HostnamePath": "/var/lib/docker/containers/bf6d4e0909541c3cf4d9c24ef4f61561873ea59e33f1aa54ba198d5ce3519c4c/hostname",
"HostsPath": "/var/lib/docker/containers/bf6d4e0909541c3cf4d9c24ef4f61561873ea59e33f1aa54ba198d5ce3519c4c/hosts",
"LogPath": "",
"Name": "/dropbox",
"RestartCount": 0,
"Driver": "overlay2",
"MountLabel": "system_u:object_r:svirt_sandbox_file_t:s0:c382,c473",
"ProcessLabel": "system_u:system_r:svirt_lxc_net_t:s0:c382,c473",
"AppArmorProfile": "",
"ExecIDs": null,
"HostConfig": {
"Binds": [
"/data/.dropbox:/opt/dropbox/.dropbox",
"/data/Dropbox (GPI):/opt/dropbox/Dropbox"
],
"ContainerIDFile": "",
"LogConfig": {
"Type": "journald",
"Config": {}
},
"NetworkMode": "default",
"PortBindings": {},
"RestartPolicy": {
"Name": "always",
"MaximumRetryCount": 0
},
"AutoRemove": false,
"VolumeDriver": "",
"VolumesFrom": null,
"CapAdd": null,
"CapDrop": null,
"Dns": [],
"DnsOptions": [],
"DnsSearch": [],
"ExtraHosts": null,
"GroupAdd": null,
"IpcMode": "",
"Cgroup": "",
"Links": null,
"OomScoreAdj": 0,
"PidMode": "",
"Privileged": false,
"PublishAllPorts": false,
"ReadonlyRootfs": false,
"SecurityOpt": null,
"UTSMode": "",
"UsernsMode": "",
"ShmSize": 67108864,
"Runtime": "docker-runc",
"ConsoleSize": [
0,
0
],
"Isolation": "",
"CpuShares": 0,
"Memory": 0,
"NanoCpus": 0,
"CgroupParent": "",
"BlkioWeight": 0,
"BlkioWeightDevice": null,
"BlkioDeviceReadBps": null,
"BlkioDeviceWriteBps": null,
"BlkioDeviceReadIOps": null,
"BlkioDeviceWriteIOps": null,
"CpuPeriod": 0,
"CpuQuota": 0,
"CpuRealtimePeriod": 0,
"CpuRealtimeRuntime": 0,
"CpusetCpus": "",
"CpusetMems": "",
"Devices": [],
"DiskQuota": 0,
"KernelMemory": 0,
"MemoryReservation": 0,
"MemorySwap": 0,
"MemorySwappiness": -1,
"OomKillDisable": false,
"PidsLimit": 0,
"Ulimits": null,
"CpuCount": 0,
"CpuPercent": 0,
"IOMaximumIOps": 0,
"IOMaximumBandwidth": 0
},
"GraphDriver": {
"Name": "overlay2",
"Data": {
"LowerDir": "/var/lib/docker/overlay2/652eb779579a24ce5d992eafcb475ffa678f7ebeff464dc15f85d823ab3fcb05-init/diff:/var/lib/docker/overlay2/78f72ac75f15f722d7ea643acad69eddf6cf5a91d2c3a1f9915c9aa5e30c1503/diff:/var/lib/docker/overlay2/dda0fd527ffc48344e1d5678b8c168ccbf5346c284fd7c068bfa4843807fb2fa/diff:/var/lib/docker/overlay2/41afff1b20d490744270517647c69b5014c95c29787292eef4bd772959244a98/diff:/var/lib/docker/overlay2/79201c911b05ae8ec8215c8a0b661289607e37f8d707debb15b3d007c1305b68/diff:/var/lib/docker/overlay2/7fc6a07d448e189c60eeb25e1a9941c9cf78ea96cf5d42ebe344d6822c2962b2/diff:/var/lib/docker/overlay2/cb8006881ba47f2a99326f5b1dc395e4fa1fa5952a4949203d59de345adb0cb2/diff:/var/lib/docker/overlay2/2aca99c92c7fea41b44e2b52e65d6664ce81f61b345bc7043a00dc1cd4426b5f/diff:/var/lib/docker/overlay2/bf7676019bc49ddce3108798199bc2a5a95137b0ce87b8bf553481adfce6cfd4/diff",
"MergedDir": "/var/lib/docker/overlay2/652eb779579a24ce5d992eafcb475ffa678f7ebeff464dc15f85d823ab3fcb05/merged",
"UpperDir": "/var/lib/docker/overlay2/652eb779579a24ce5d992eafcb475ffa678f7ebeff464dc15f85d823ab3fcb05/diff",
"WorkDir": "/var/lib/docker/overlay2/652eb779579a24ce5d992eafcb475ffa678f7ebeff464dc15f85d823ab3fcb05/work"
}
},
"Mounts": [
{
"Type": "bind",
"Source": "/data/.dropbox",
"Destination": "/opt/dropbox/.dropbox",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
},
{
"Type": "bind",
"Source": "/data/Dropbox (GPI)",
"Destination": "/opt/dropbox/Dropbox",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
}
],
"Config": {
"Hostname": "bf6d4e090954",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"ExposedPorts": {
"17500/tcp": {}
},
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"LANG=C.UTF-8",
"LC_ALL=C.UTF-8",
"POLLING_INTERVAL=5",
"SKIP_SET_PERMISSIONS=false"
],
"Cmd": [
"/opt/dropbox/bin/dropboxd"
],
"ArgsEscaped": true,
"Image": "otherguy/dropbox:latest",
"Volumes": {
"/opt/dropbox/.dropbox": {},
"/opt/dropbox/Dropbox": {}
},
"WorkingDir": "/opt/dropbox/Dropbox",
"Entrypoint": [
"/docker-entrypoint.sh"
],
"OnBuild": null,
"Labels": {
"maintainer": "Alexander Graf alex@otherguy.io",
"org.label-schema.build-date": "2021-06-25T13:13:39+02:00",
"org.label-schema.description": "Standalone Dropbox client",
"org.label-schema.name": "Dropbox",
"org.label-schema.schema-version": "1.0",
"org.label-schema.vcs-ref": "9759ba8",
"org.label-schema.vcs-url": "https://github.com/otherguy/docker-dropbox",
"org.label-schema.version": "1.9.0"
}
},
"NetworkSettings": {
"Bridge": "",
"SandboxID": "f47b9c24c8f3e83e7a0ee2806fae787b946542ce4a91fc45300cf905e162d5e6",
"HairpinMode": false,
"LinkLocalIPv6Address": "",
"LinkLocalIPv6PrefixLen": 0,
"Ports": null,
"SandboxKey": "/var/run/docker/netns/f47b9c24c8f3",
"SecondaryIPAddresses": null,
"SecondaryIPv6Addresses": null,
"EndpointID": "",
"Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"IPAddress": "",
"IPPrefixLen": 0,
"IPv6Gateway": "",
"MacAddress": "",
"Networks": {
"bridge": {
"IPAMConfig": null,
"Links": null,
"Aliases": null,
"NetworkID": "21b3317bf4bb26264151b8651acca3846b1efcd022aeac3d511ba9c8f511a771",
"EndpointID": "",
"Gateway": "",
"IPAddress": "",
"IPPrefixLen": 0,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"MacAddress": ""
}
}
}
}
]
# docker exec -it dropbox gosu dropbox dropbox status
Connecting...
and it hangs forever. here are the docker logs:
I ran a shell inside the docker container to verify network connection:
root@bf6d4e090954:/opt/dropbox/Dropbox# curl google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
\<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
What else can I check or provide to help figure out this problem?
thank you!
Hi and thanks for the report!
I fear this might be something to do with Dropbox itself, not with this Docker container. But first, let's check a few things:
- What are you running this on? Linux or Mac?
- Are you connecting from a home network or a corporate network or perhaps some other shared connection?
One thing you can try is to use a mobile phone hotspot and connect through this to see if it's working.
Thank you for responding. As I stated, this is running on CentOS 7. This is on a server in a rack in a corporate data center. I included the curl output from within the container to help indicate that the network connection is working. In my example, I used google.com because the output was relatively short. Accessing dropbox.com with curl also works fine.
There are other systems on the same network running this container which also work fine.
It may well be a problem with the dropbox client itself. Since dropbox won't support their linux client, I was hoping you (or anyone else who might come across this issue) might be familiar enough with it to help me find some kind of diagnostic option.
I appreciate any insight you may be able to offer.
thanks,
-wes
Interesting. My suspicion was that it's a corporate network blocking the connection to the Dropbox API. But since you say you have other systems on the network that have no such issues, this might not be the case.
Did you already link your Dropbox account or does it get stuck before that?
Can you please post the full docker run command that you are using?
Could you run the container not in daemon mode but with -it instead and post the full output here?
Do you know how the client connects to the API? I would like to attempt to reproduce the connection using tools that will give useful output. What port does it use, etc.
It worked for a few years up until a few months ago, then suddenly stopped. It wasn't super high priority at the time, but now people are starting to complain so I need to figure out what the problem is.
I attempted to "rm" the container from docker and re-run it. It does not currently prompt to link the account, however I have not yet tried to delete/rename the .dropbox folder. So it's still using the auth data from before. I suppose I should try that as well.
I have tried various docker run commands to try to narrow down where the problem is. Here is the latest one:
docker run --detach -it --restart=always --name=dropbox -v "/data/.dropbox:/opt/dropbox/.dropbox" -v "/data/Dropbox (GPI):/opt/dropbox/Dropbox" otherguy/dropbox:latest
I am using -it in the docker run command since that is what is in the instructions for running this container. The output is the same as what it shows in the log output which I linked to.
Additionally, at one point I launched a root shell in the container and started dropbox that way. That DID prompt me to link the account, however I didn't complete that step since I didn't really want it running as root. Plus, it would not persist past a container restart, and I'd be back where I started. But at least this is one more piece of support that the API calls are able to reach the dropbox servers.
thanks,
-wes
I attempted to "rm" the container from docker and re-run it. It does not currently prompt to link the account, however I have not yet tried to delete/rename the .dropbox folder. So it's still using the auth data from before. I suppose I should try that as well.
Yes, if there is a .dropbox folder present, it will use the auth information from there.
Could you try deleting it (or not mounting it into the container)?
It's possible that some dropbox internal upgrade corrupted a file in that folder.
I am using -it in the docker run command since that is what is in the instructions for running this container. The output is the same as what it shows in the log output which I linked to.
-t : Allocate a pseudo-tty
-i : Keep STDIN open even if not attached
Generally this is only necessary when not running in detached mode (-d / --detach). It is not harmful though and is helpful when you need to debug it.
Additionally, at one point I launched a root shell in the container and started dropbox that way. That DID prompt me to link the account, however I didn't complete that step since I didn't really want it running as root. Plus, it would not persist past a container restart, and I'd be back where I started. But at least this is one more piece of support that the API calls are able to reach the dropbox servers.
Yes, that is due to the fact that the dropbox daemon when run as root would look in a different place for the .dropbox settings folder.
But, as you mention, it does show that a connection is possible!
My suspicion that the .dropbox folder is to blame is growing. One other possible issue might be permissions on the Dropbox data folder.
Generally, if this is something that should be running continuously in a production environment, you should make sure to set the correct timezone and the correct uid/gid on the container:
Ok, I renamed .dropbox and removed and re-installed the container. It prompted to link the account, which succeeded, but left us back where we started.
I also ran it without detaching as you requested: https://pastebin.com/XZDHsp4W
# docker exec -it dropbox gosu dropbox dropbox status
Connecting...
What else can we try?
thanks,
-wes
Can you please try without mounting any of the 2 volumes you do now?
Instead, please pass in the volumes for timezone and localtime, as described here: https://github.com/otherguy/docker-dropbox#time-zones
-v "/etc/timezone:/etc/timezone" \
-v "/etc/localtime:/etc/localtime" \
Also, please use the correct UID and GID (though it won't have any effect for now, as you're not mounting the data volume).
See https://github.com/otherguy/docker-dropbox#persisting-data
Well that exposed an oddity on the system: /etc/timezone was an empty directory. Yet, the system showed the correct time, in the correct timezone. Just in case, I went ahead and fixed it to be a file.
I am not sure what you mean by the "correct" UID and GID - the defaults are 1000:1000, which I have arranged to be the dropbox user on my system for convenience. Everything in our sync directory is owned by this user and group. We skip the initial chmod because it takes upwards of an hour to complete each time we restart.
This resulted in a supposed permissions error, which doesn't make sense since there is no directory mounted.
At the end it says something about "Filesystem "Unknown(2035054128)" not supported" which I'm guessing is spurious.
-wes
Ah, I forgot how Centos handles timezones. On Centos it would be /usr/share/zoneinfo/ and /etc/localtime. You can also completely skip mounting the volumes and instead pass in the correct timezone like so: -e "TZ=Australia/Brisbane" and use readlink /etc/localtime | sed 's#^.*/zoneinfo/##' to get your current one. See https://github.com/otherguy/docker-dropbox#time-zones
Regarding the UID and GID, that is one way of doing it. You could have instead opted to change the GID / UID of the container to the local one. See: https://github.com/otherguy/docker-dropbox#time-zones
Regarding the dropbox error, that is super weird. I cannot replicate that on either a Debian or a macOS system. However, it seems somebody had a similar issue, also on Centos: https://www.dropboxforum.com/t5/Dropbox-installs-integrations/Dropbox-unable-to-start-on-Linux-container/m-p/537587#M109954
The supposed permissions error is merely a helpful message because that is actually the case, most of the time.
So it seems that on Centos you need the volumes for data and config mounted. Could you try that please, but with completely empty, fresh directories?
Empty, fresh directories is what I did last time.
-wes
Can you confirm that it's actually stuck on Connecting... and not Starting...?
Could you also please check /var/log/messages to see if SELinux is blocking dropbox?
Definitely "Connecting" - that was a copy/paste.
SELinux is disabled on both systems.
-wes
That is very odd. I'm going to attribute this to Dropbox itself but I'll keep the issue open for now.
Unfortunately, I can't get the newest dropbox version to get past Starting... on any system if I reset the settings, weirdly. With an existing .dropbox folder, it works.
@otherguy do you have a debug or development version of the dropbox container? maybe something with more tools available, like strace etc?
I don't have one but it's easy to make for yourself!
# Dockerfile
FROM otherguy/dropbox:1.10.0
RUN chmod 1777 /tmp \
&& apt-get update \
&& apt-get install -y --no-install-recommends --fix-missing \
strace \
&& chmod o-w /tmp \
&& chmod g-w /tmpThen just build it:
$ docker build --tag the-wes/dropbox-debug:1.10.0 .At this point we have switched to Maestral which is more-or-less working for us. I do very much appreciate you taking your time to try to help us with this. Thank you! I am going to close this out now.