Child Item

Cannot open Dropbox website through Linux client

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?

Find more posts tagged with

Desktop

Web

Install

Linux

Insightful

Closed - Not for right now

Accepted answers

Uninstalling the snap version (sudo snap remove firefox) and installing the traditional version via `sudo apt-get install firefox` resolved the problem.

The xdg-mime query default text/html now returns the expected firefox.desktop which you @Здравко initially flagged as suspicious.

What a pain 🙂

All comments

Hey @andreamoro, I'd be happy to help with that!

Do you get this error with a specific file type or no?

Could you send me a screenshot of what you see when trying to open on the website, so I can have a clear visual?

Thank you!

I'm not on that computer now, but it is a URL not found. Since the URL requested is starting with tmp:// or file:///tmp/ and the browser doesn't know hot to resolve that URL, the error shows up.

I did try to change the browser into Chromium (default is Firefox) without luck. Don't have temp files restrictions as far as I can tell, but it mostly depends on where this tmp file is being created.

I guess that somewhere in the installation process the mime-type if any, or the path resolution has not been created?

No, as I said, I'm just pressing the globe button from the dropbox icon tray. But, even if I right click on the contextual-menu View on dropbox, the result is the same, no matter which file I try to open.

See below a screenshot from Firefox

Screenshot from 2021-10-31 09-05-11.png

and one using Chromium which I temporarily reverted as default browser (btw, until quitting, the app continues to read the previous browser as the default).

Screenshot from 2021-10-31 09-08-12.png

Tmp folder settings are 1777, so I don't see why DropBox should not be able to create the temporary file (as per the previous answer).

Perhaps this is the problem? Since my logged in user is the only one able to remove file I create, it might be that DropBox is trying to create files with my logged in account, but remove with its own process name?

Hi @andreamoro, thanks for all the additional info!

It seems your issue is similar to the one mentioned in this thread.

Want to take a look at what has been also mentioned there?

As I said, Firefox is already my default browser

All the commands given are just to check what the default browser is, except one that seems to setup a smart url. The path in that case will never match with my system, so some clarity around how to create them might be helpful.

Hi @andreamoro, this is something related to how your OS works, and isn't related to Dropbox itself.

If the tmp file can't be accessed by the browser, then it's possible that the creation of the file is being prevented somehow in your OS.

@Jayassuming this is the case, how can this be fixed? You guys support Linux Ubuntu, so I would expect some sort of log to be inspected?

Can you tell me where this log is, or what else can be done?

As far as I can tell, the problem is the Dropbox client that is not writing the file at all. Inspecting the /tmp folder the browser attempts to load the file from, reveal no files at all.

@andreamoro wrote:
... You guys support Linux Ubuntu, so I would expect some sort of log to be inspected?
...

Hi @andreamoro,

Linux is NOT first class citizen on Dropbox (and not only), despite growing usage in many fields. Big companies are "conservative" and takes some time adaptation to new realities, so "some sort of log to be inspected" sounding very abstract to the PR staff moderating the forum. In other words better don't rely.

@andreamoro wrote:
... Inspecting the /tmp folder the browser attempts to load the file from, reveal no files at all.

🤔Wow... "no files at all" is sounding very strange! 🧐 Are you sure?! The "tmp" folder is used by many applications (user programs and system services) to keep (as the name suggest) temporary files. Inability to access to /tmp would carries a lot of headaches, no only Dropbox application related.

Let's find out what's the current state. Execute following in terminal:

ls -ld /tmp
ls -al /tmp | wc -l

What's the both commands output? Can you post the result?

Take in mind that the files, you are referring above, are kept by Dropbox application for a minute, at most. If you have checked after that they have gone already. One more thing, you may have ignored, is actual file name - only the first part of the URL, up to the hash sign. The rest is an argument passed to the browser (everything after the hash and the hash sign itself). So be careful what you are looking for to be able find it. 😉

Also take in mind that default web browser, protocol handler, and file handler are completely different things.

They can keep the same or different applications. The screenshot you have posted above, showing your default web browser, has nothing to do with html file handler. Don't mess them! You can find (and possibly change) the file handler on Properties dialog in Nautilus (Open With tab) or using following command:

xdg-mime query default text/html

Hope this gives direction and adds some clarity.

@Здравкоthanks for coming back to me. When I said no files at all in the tmp folder, I was in fact not clear enough. I meant no Dropbox files.

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

watch ls

to capture changes?

@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. 😉

Is that something I can use straight in the shell? Without any scripting?

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

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?

@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

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

@Здравко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.

$ 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.

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?

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.
...

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?

@Здравко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.

@Здравко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).

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?

@andreamoro wrote:
... 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).
...
But the interesting thing is that at this stage if I do a ctrl+O ... I can open that file regularly.
.... 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.
...

I'm not beside you, but hope you are aware described above isn't possible. Your words can only make me speculate.

If I have to bet, you are messing 2 (or more) 'tmp' folders; one is subfolder of the actual root folder and another placed within additional device or partition subfolder. Note that Nautilus (on your first screenshot) hides leading part of the path if current folder is within additional drive/partition; only that part of the path following after used mount point is shown! In such a way 2 completely different folders sharing the same name ('tmp' in particular) can appear pretty similar. Maybe you are getting confused in such a way.

To be sure, you can check the full path. One way is through context menu of file 'saving.html', take a look on the path in Properties. Is it /tmp/saving.html or something like /path/to/tmp/saving.html appears there? Another way is while you are on the same view in Nautilus (containing 'saving.html'), press Ctrl-L so address line containing actual folder path appear on top. Is it /tmp or something like /path/to/tmp appears there? Does the file 'saving.html' remain in the pointed folder content if you type '/tmp' explicitly in the address line and press Enter-key or content is changing to something else matching terminal results? 🧐

In short, make sure what you're looking on!

@Здравкоbelieve me that I'm as puzzled as you are .... and I doubled checked right now for possible mistakes due to the late hour when I answered.

But both the folders are technically pointing to the same location, but they don't have the same content.

It looks like the /tmp/ folder Firefox is saving is symbolic link to somewhere, that's me guessing here. Although there is not a chance to use the CTRL+L trick to show the full path as it happens in Nautilus.

But see below the Fireforx autocompletion when I ask for the /tmp/ folder. A bunch of files.

Whereas, below the content of the /tmp folder from Nautilus

The test file date is Wednesday, when I moved there manually.

And here we go ... Firefox was installed with Snap... and has a result it creates some kind of shims for the temporary folder.

That's where the content is. I start to believe this Snap is more a pain than a solution.

Uninstalling the snap version (sudo snap remove firefox) and installing the traditional version via `sudo apt-get install firefox` resolved the problem.

The xdg-mime query default text/html now returns the expected firefox.desktop which you @Здравко initially flagged as suspicious.

What a pain 🙂

Featured Links