cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Want to learn some quick and useful tips to make your day easier? Check out how Calvin uses Replay to get feedback from other teams at Dropbox here.

Apps and Installations

Have a question about a Dropbox app or installation? Reach out to the Dropbox Community and get solutions, help, and advice from members.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Re: Cannot open Dropbox website through Linux client

Cannot open Dropbox website through Linux client

andreamoro
Helpful | Level 6
Go to solution

Similarly to the issue described here, on a fresh Ubuntu 20.04 with the dropbox client recently installed, by the time I press the button on the app to say "Open the Dropbox site", the browser opens a new window with a local file in the url starting with tmp which can't resolve in a proper site.

The issue happens in both Firefox and Chromium.

 

How can this be solved?

23 Replies 23

Здравко
Legendary | Level 20
Go to solution

@andreamoro wrote:

...

I will be looking into the tmp folder again later, perhaps going with a

watch ls

to capture changes?


I don't think using proposed command is most convenient way. You may want consider following to trace what's going on (almost in real time - time step one second in particular):

i=0; while [[ $((i++)) -lt 60 ]]; do touch ~/timeref; sleep 1; echo "$i: "; find /tmp/* -cnewer ~/timeref -exec echo {} \; 2> /dev/null; done; rm ~/timeref

Good luck. 😉

andreamoro
Helpful | Level 6
Go to solution
Is that something I can use straight in the shell? Without any scripting?

Здравко
Legendary | Level 20
Go to solution

It's a script byself. A single line script. Copy and paste it in your terminal as is. 😉 I assume your shell is 'bash'.

andreamoro
Helpful | Level 6
Go to solution

Thanks @Здравко I never realised I could do this in a one line.

So let's go back to your questions

 

ls -ld /tmp

>>> drwxrwxrwt 31 root root 4096 Nov 4 08:22 /tm
ls -al /tmp | wc -l
>>> 60

So the /tmp folder is indeed used and it contains 60 other files. And settings are quite right for what I can say (but here you know much more than I do).

And the default HTML file handler is indeed Firefox.

xdg-mime query default text/html
>>> firefox_firefox.desktop

And finally your script that worked like a charm,

 

1: 
/tmp/tracker-extract-3-files.1000
2: 
3: 
4: 
5: 
6: 
7: 
8: 
/tmp/dbxl2rwj1vev.html
9: 
10: 
11: 

 

The file is created apparently ... so why isn't then opened?

Здравко
Legendary | Level 20
Go to solution

@andreamoro, everything seems almost normal. The only thing I can't understand is the desktop file name:


@andreamoro wrote:

...

xdg-mime query default text/html
>>> firefox_firefox.desktop

...


By default Firefox desktop file looks "firefox.desktop" (without name doubling and additional underbar). Have you created some extra desktop file with custom settings or so? 🤔

 

You can try investigate further by try save some web page locally (doesn't matter what exactly - just for check). Find out the place of main HTML file (typically carries the page title as file name). Execute following in terminal:

xdg-open file:/<path/to/your/just/downloaded.html>

Where <path/to/your/just/downloaded.html> is path to downloaded page main file (as the pseudo path "suggests" 😉). What's going on? 🧐 Is the downloaded page opening or not?

By the way... Post also the result from:

grep text/html= /usr/share/applications/mimeinfo.cache ~/.local/share/applications/mimeinfo.cache

 

andreamoro
Helpful | Level 6
Go to solution
Will try on my return, but Firefox is the instance I found when Ubuntu 21.04 completed the installation process, so can't really say anything on that

andreamoro
Helpful | Level 6
Go to solution

@Здравкоso here I am.

 

I can definitely open an html saved file with the command below.

xdg-open ~/Downloads/test.html 

 

I have tweaked the syntax, because apparently whether I want a URL or a file ... I just specify the resource and the browser (Firefox) opens it.

With your initial syntax, returning an "operation not supported" I had some doubts the mime type was not associated. But clearly I didn't pay too much attention to the error.

That said, I still verified if the correct type is associated, and it is indeed.

 

andreamoro_0-1637148320411.png

$ cat ~/.config/mimeapps.list | grep http                      
x-scheme-handler/http=firefox_firefox.desktop
x-scheme-handler/https=firefox_firefox.desktop

 

However, the last of your command you asked me to try, doesn't output anything. Not sure what is expected to do.

$ grep text/html= /usr/share/applications/mimeinfo.cache ~/.local/share/applications/mimeinfo.cache
>>>

 

But here it is the problem. I tried to move the test.html file in the /tmp folder, and trying to re-open it as per the above produce the same error, File not Found, although in this case the file is there since it was manually created.

andreamoro_1-1637148644277.png

The file has been clearly created with my user:group, so I guess it's a permission problem, and I guess it's the same case for dropbox?

Although changing the permission to root:root doesn't solve the problem, so I'm still puzzled on what the root cause is.

 

Any idea?

 

Здравко
Legendary | Level 20
Go to solution

Hi @andreamoro,

Hmm... Seems like a complete mess in your system.

 


@andreamoro wrote:

...

I can definitely open an html saved file with the command below.

xdg-open ~/Downloads/test.html 

 

I have tweaked the syntax, because apparently whether I want a URL or a file ... I just specify the resource and the browser (Firefox) opens it.

...


I'm not sure what you have done, but both with or without leading "file:" are equivalent. If the leading is missing it's implied. One thing I suspect is usage of leading tilde in path together with "file:". In such a case the path is invalid. 🙂 If you want use of relative path with leading "file:", it should start from your current working directory (without any additional symbols), otherwise it should be absolute path. The tilde is resolved correctly only at the beginning of the path, not inside!

 


@andreamoro wrote:

...

However, the last of your command you asked me to try, doesn't output anything. Not sure what is expected to do.

$ grep text/html= /usr/share/applications/mimeinfo.cache ~/.local/share/applications/mimeinfo.cache
>>>
...

"Doesn't output anything" is something really strange. Here has to be list of all applications registering itself as able to handle particular type (i.e. HTML file in particular). In the output should be available all desktop files for all installed browsers (for example) and any other similar applications if any. That's why empty output (without even an error) is strange. 🤔 Looks like something isn't completed with the install (especially the cache build). You can try Firefox reinstall to fix this.

I have no idea why you have posted protocol handlers, but with little bit tweaked command similar information as the one missing above can be received - file handlers (despite not the absolutely same, but probably still usable):

$ grep text/html= ~/.config/mimeapps.list

 


@andreamoro wrote:

...

But here it is the problem. I tried to move the test.html file in the /tmp folder, and trying to re-open it as per the above produce the same error, File not Found, although in this case the file is there since it was manually created.

andreamoro_1-1637148644277.png

...

Wow... That's really strange! You should create the file with your own user and group (Dropbox create its file in the same way). Check what's there actually by using something like:

ls -l /tmp/test.html; id

Also, make sure you are trying to open the file as the same user, NOT as someone else! Only in such case (different users) permissions could be an issue.

 

I confess have no idea what could be the reason for the last, outside of already mentioned. Try different things to check what's there. Can you open the file using "gedit" for example? 🧐 Is there any difference while opening your html using the command above or using "Open... (Ctrl-O)" within the browser?

andreamoro
Helpful | Level 6
Go to solution

@ЗдравкоI'm not sure how my system can be such a mess 🙂 ... after all it's a brand new installation from Canonical ... and it has less than a week (overall) of usage.

I doubt I have been able to destroy it already 😄

 

Let me return in a moment to the other questions.

andreamoro
Helpful | Level 6
Go to solution

@Здравкоthis is really strange. I can save the saving.html file via the browser, but when I try to search for it via the CLI or the file explorer, the file can't be seen (neither with the current user nor with the root impersonation).

 

andreamoro_0-1637186854492.png

 

andreamoro_1-1637186900119.png

I'm now really confused on where the file is.

 

But the interesting thing is that at this stage if I do a ctrl+O ... I can open that file regularly.

But I can't use the xdg-open, because the file cannot be reached via the CLI. It doesn't seem to be there

 

 

Going back to my previously created file (the one in ~/tmp/test.html, later moved into the /tmp). A gedit opens the file correctly, but the xdg-open does not. It prompts that File not found error in the browser. Opening the file with the browser is not possible, because the browser doesn't see the test.html file.

 

 

Any idea?

Need more support?