tomfool

Members
  • Posts

    10
  • Joined

  • Last visited

Everything posted by tomfool

  1. Hi vmontserrat "DROPBOX_SKIP_UPDATE" variable set as "True" (Manually entered into the Extra Parameters area) was a fix we used a while back, when the latest Dropbox version was throwing errors. To give context, we had to use a different repository from otherguy, when ken-ji's version was no longer able to connect to Dropbox. Unfortunately, the other repository had issues as well and so we had to force it not to update. If you are starting afresh, then DROPBOX_SKIP_UPDATE might not apply to you.
  2. I got that message a while back, but took a chance and removed "TRUE" from the DROPBOX_SKIP_UPDATE: field. After a few attempts this worked for me, but I had to rename the location of my Dropbox user files, to create a fresh copy of my files, it seemed to get stuck otherwise.
  3. When you switched repositories, was it an entirely fresh install? Also, what is in your Repository and Docker Hub URL fields?
  4. I think it is the folder in /appdata/dropbox called Dropbox. As I can replicate this error even if I use a different folder name for the location of my files and lower case the container folder.
  5. Sorry that's my mistake. I forgot that I swapped repositories too, so it's probably not a valid post here. However, I think the second repository I tried had the exact same issues that we were experiencing with roninkenji's So there might be a clue in there somewhere for you Kenji. I'm not knowledgable enough to work it out, sorry. Anyway, after deleting the container, image and files in appdata I put otherguy/dropbox:1.9.0 in the repository field, put the extra parameters info in and followed the instructions as normal. I really appreciated the speedy responses from you Kenji. Please let me know if you'd like me to test out your repository again, if you make any changes.
  6. I finally got it working in bridge mode by specifying dropbox version 1.9 and setting dropbox_skip_update to true in extra parameters
  7. I dont suppose it has something to do with the network type?
  8. Hi Ken-ji What is the usual time-period for folders to start appearing from Dropbox? I've been up and running for 30 mins now and all I am getting in the console is "Starting...", when I run this: sh-4.3# su - nobody -c 'dropbox.py status' Starting... The logs show: dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/cryptography.hazmat.bindings._openssl.cpython-38-x86_64-linux-gnu.so' dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/cryptography.hazmat.bindings._padding.cpython-38-x86_64-linux-gnu.so' dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/psutil._psutil_linux.cpython-38-x86_64-linux-gnu.so' dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/psutil._psutil_posix.cpython-38-x86_64-linux-gnu.so' dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/apex._apex.cpython-38-x86_64-linux-gnu.so' dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/tornado.speedups.cpython-38-x86_64-linux-gnu.so' dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/wrapt._wrappers.cpython-38-x86_64-linux-gnu.so' dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/PyQt5.QtWidgets.cpython-38-x86_64-linux-gnu.so' dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/PyQt5.QtCore.cpython-38-x86_64-linux-gnu.so' dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/PyQt5.QtGui.cpython-38-x86_64-linux-gnu.so'
  9. I am also having this problem Edit: Rebooting, doing the unraid-api restart and going to tools/registration and download/install the upgrade key worked the second time. Maybe I did it in the wrong order the first time??