Need to see if your shared folder is taking up space on your dropbox 👨💻? Find out how to check here.
Forum Discussion
Solved
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 ...
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 🙂
Здравко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.
