Can't Select Home Directory for JDK because IntelliJ can't see it?

Question

My system is Linux Mint 18.3 Cinnamon 64-bit.

I've installed IntelliJ-IDEA and Default-jdk (openjdk-8-jdk) using the software manager.

I can see what I believe to be the JDK folder under either /usr/lib/jvm/java-1.8.0-openjdk-amd64 or /etc/java-8-openjdk when browsing with the file manager (Nemo) or the terminal. But it doesn't matter because IntelliJ can't see either folder anyway. In fact, when trying to Select Home Directory for JDK, IntelliJ only seems to have visibility to 14 sub-folders (out of hundreds) under /usr/lib.

Not even sure how to launch IDEA from the command-line using sudo, e.g. to test that the issue is permission-related, since it is apparently being launched vicariously via flatpak.

Seems like this should be simple. I'm not sure what I'm doing wrong.

Answer 1

As others said - sandboxing is a feature, not a bug.

I think @Kevin Dubois' answer should perhaps be preferred where applicable (installing via flatpak the thing you want to share), but there is another solution to this problem if you would like to continue using flatpak

How to find /etc and /usr paths in a flatpak:

As mentioned at the end of this section of the documentation:

• /etc is mounted at /var/run/host/etc for the flatpakked software
• /usr is mounted at /var/run/host/usr for the flatpakked software

You also need to grant the --filesystem=host:ro permission to your app if it doesn't have it yet (see below on how).

If you need to find or manage other paths:

NB: It is generally a good idea to give software as little extra access as possible. That's why it is preferable to use the optional :ro suffix when granting access to a path to make it accessible in read-only. You will also be partly responsible if some software abuses the access it has to your device.

There's some useful path variables in the filesystem permissions reference and a lot of additional information about filesystem permissions here.

GUI option:

Flatseal is the most convenient option.

It only manages permissions on the user-level, so if you need to change settings for all users (usually not), then turn to the next section.

CLI option:

The examples below are for managing the path /var/lib/gems for the flatpak app com.jetbrains.IntelliJ-IDEA-Community. The 3 last commands are given with the --user flag for a user-level change. Without the flag and with sudo prepended the change would be applied to all users.

To check current permissions:

flatpak info --show-permissions com.jetbrains.IntelliJ-IDEA-Community

To grant access:

flatpak override --user --filesystem="/var/lib/gems":ro com.jetbrains.IntelliJ-IDEA-Community

To forbid access:

flatpak override --user --nofilesystem="/var/lib/gems" com.jetbrains.IntelliJ-IDEA-Community

To reset permissions to the initial state:

flatpak override --user --reset com.jetbrains.IntelliJ-IDEA-Community

Answer 2

I had the same problem with IntelliJ installed with Flatpak on Fedora 29. I believe (but correct me if I'm wrong) that Linux Mint's Software Manager also uses flatpaks.

It turns out this is one of those "it's a feature not a bug" situations due to the way Flatpak sandboxes applications. As per the documentation at http://docs.flatpak.org/en/latest/sandbox-permissions.html:

Sandbox Permissions One of Flatpak’s main goals is to increase the security of desktop systems by isolating applications from one another. This is achieved using sandboxing and means that, by default, applications that are run with Flatpak have extremely limited access to the host environment. This includes:

No access to any host files except the runtime, the app and ~/.var/app/$APPID. Only the last of these is writable. No access to the network. No access to any device nodes (apart from /dev/null, etc). No access to processes outside the sandbox. Limited syscalls. For instance, apps can’t use nonstandard network socket types or ptrace other processes. Limited access to the session D-Bus instance - an app can only own its own name on the bus. No access to host services like X11, system D-Bus, or PulseAudio. Most applications will need access to some of these resources in order to be useful. This is primarily done during the finishing build stage, which can be configured through the finish-args section of the manifest file (see Manifests).

One way around this is to install JDK versions using flatpak as well, eg.

flatpak install flathub org.freedesktop.Sdk.Extension.openjdk9 org.freedesktop.Sdk.Extension.openjdk10 org.freedesktop.Sdk.Extension.openjdk11

Another way around this is the solution CrazyCoder provided, which is to install IntelliJ using their tar.gz. This eliminates the entire sandbox constraint altogether.

Answer 3

You can try installing IntelliJ IDEA from here and see if it works better. .tar.gz distribution can be launched using ./idea.sh. Note that you can also create a launcher script using Tools>Create Command-line Launcher. This should work with any version.

Answer 4

The hint to the mounted directories by @Carolus worked perfectly for me: On my Linx Mint the jdk had been installed within /usr/lib/jvm/java-11-openjdk.

(found by usage of "which java" and using the result with "readlink -e ")

Selected /var/run/host/usr/lib/jvm/java-11-openjdk within the Idea addJdk dialog instead and it works! No change of flatpak permissions was required.

Answer 5

To prevent overriding permissions with flatpak

Move jvm folder to a new folder in home directory

Flatpak has specific blacklisted directories, while home is whitelisted.

mkdir ~/ForceHome

sudo mv /usr/lib/jvm ~/ForceHome

Create a symbolic link in /usr/lib/jvm

This in case any files are still pointing there, and so you can point to /usr/lib/jvm with programs that can access that folder.

sudo ln -s ~/ForceHome/jvm /usr/lib/jvm

Select /ForceHome/jvm/jdk_version when selecting the sdk in Intellij

replace jdk_version with the openjdk version that you have downloaded