X11docker: Master breaks home directory mount

[01e9]

6.6.1 works as before. With master home is not mounted anymore. Maybe it's mounted somewhere else but I need the container to have exactly the same home path as on host machine (old behavior).

https://github.com/01e9/docker-ide/blob/ee7d5eeb140e2409bedc09463d9cbbcaf894b828/ide#L60

[mviereck]

In my test runs --home=$HOME works as intended.
One thing has changed: In master the container path is /hosthome/username instead of /home/username.

It's a bit unfortunate that you need exactly the same path. Don't your applications regard variable HOME or the /etc/passwd entry but use hardcoded pathes instead?

I'd like to avoid using /home in container.
Especially I'd like to avoid a mess of shared host folders.
For example, if one uses the combination --home --share ~/Videos, the shared ~/Videos folder would hide the containers ~/Videos folder from --home that also might have content.

[mviereck]

A possible setup that is also backwards compatible:

--share $HOME --env HOME=$HOME

[01e9]

I need /home because I launch software from host machine and it may have configs with absolute paths. Also I tell users of my tool that exactly the same host home path is available in docker. Adding a rule about /hostname will add confusion.

---

--share $HOME --env HOME=$HOME

Doesn't work. For some reason IDE doesn't understand that /home/user exists and treats /tmphome/user as home. So all my IDE configs are lost (on each start it prompts to configure IDE).

---

If next x11docker version is not backwards compatible and you will decide not to support old --home behavior, I will copy x11docker 6.6.1 in my project.

[mviereck]

For some reason IDE doesn't understand that /home/user exists and treats /tmphome/user as home.

That's unfortunate, too. It seems that IDE looks for the home path in /etc/passwd and ignores variable HOME. That is a bug in the IDE. HOME should take precedence over /etc/passwd.
Is it possible to make a bug report to the IDE developers?

If next x11docker version is not backwards compatible and you will decide not to support old --home behavior, I will copy x11docker 6.6.1 in my project.

I hope we'll find a good solution.

[01e9]

Is it possible to make a bug report to the IDE developers?

Yes. Scroll down, there is a link "Bug and issue tracker" https://www.jetbrains.com/webstorm/
I think you should open the bug report because they may ask more details and I am not so familiar with Linux internals.
To reproduce the problem you can download the IDE and use it for 30 days trial.

[mviereck]

I think you should open the bug report because they may ask more details and I am not so familiar with Linux internals.

I've just logged in and tried to open a ticket. But because I am not familiar at all with the IDE, I even don't know which affected project should be selected from a long list.

Please open the ticket yourself and give me a link. Also provide them a link to this ticket. I'll enter there if there are questions.

Basically it is just:
"IDE does not regard environment variable HOME".

Issue:
The IDE ignores environment variable HOME and uses the entry in /etc/passwd instead.
In general environment variable HOME should take precedence over entries in /etc/passwd. All applications I am familiar with do regard HOME.

Background:
In an Docker/x11docker container setup the users HOME ist not in /home and also different from the user entry in /etc/passwd.

Expected behaviour:
The IDE should regard and use environment variable HOME to store and read its configuration.

[01e9]

I even don't know which affected project should be selected from a long list

Their devs/moderators will fill in the missing details later.

---

https://youtrack.jetbrains.com/issue/WEB-45054

You can click "Watch issue" to get email notifications.

[01e9]

I think that issue may be solved in a few months or more, because it's not critical and not related to actual IDE/programming behavior.

So until they will fix that I will copy x11docker in my project.

Hm, it seems more convenient like this because I don't require users to install manually an external tool, and safer because I prevent compatibility issues when some x11docker options will be removed/changed (like happened here). A few times a year I will update x11docker to latest version and adapt options if required.

[01e9]

You can reopen it if you will be in the mood to make it backwards compatible (old behavior, not HOME var trick)

[mviereck]

I did a change in x11docker that sets the same HOME in container for the special case --home=$HOME. For this case the old behaviour is restored.

Webstorm (as every java app) uses user.home System property to detect the user home dir; looks as if java doesn't take your $HOME environment variable into account when running in the docker container.
You can overwrite the default system property value by passing -Duser.home= to the IDE (can be done in in Help | Edit Custom VM Options, for example)

So it seems to be a java bug.

[mviereck]

Hm, it seems more convenient like this because I don't require users to install manually an external tool, and safer because I prevent compatibility issues when some x11docker options will be removed/changed (like happened here). A few times a year I will update x11docker to latest version and adapt options if required.

You can do that, of course. I just want to point at two things:

• x11docker follows the semantic versioning scheme.
  
  
  
  • Documented options won't be removed in minor version changes. Within the 6.x series, options might be deprecated, but will continue to work.
  
  
  • Removing an option requires a major version bump to 7.x. For documented options you would only have to check your setup if x11docker gets a major version bump.
  
  
• Having the same /home path on host and in container with option --home hasn't been documented and was not reliable in previous versions.
  
  
  
  • Without option --home the path was already different.
  
  
  • If one has a different path than /home/username on host, the container path could differ from the host path even with option --home.
  
  
  • Only the new commits in master (https://github.com/mviereck/x11docker/commit/667dbc1f37522e4a25dfcdbbc0b5aab05e083f03 and https://github.com/mviereck/x11docker/commit/bfec46948d9d839192dc28e081349ec5ec87ec2b) intentionally set the same path on host and in container for --home=$HOME. (This is currently not documented elsewhere, but I've made a note to myself in the code concerning this ticket. The special setup --home=$HOME is less affected by the sharing mess issues I've mentioned above.)