Cannot open Dropbox website through Linux client

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

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

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