Error during installation/run

[oywino]

I'm running Docker 1.11.2 on a QNAP server.
I downloaded your Wine Dev 1.7.44 and tried to install it, then I got the following error:
Error 2017/02/19 17:40:18 Container admin Failed to do background task (create, wine-1) Error 2017/02/19 17:40:18 Container admin Background task error for create: 500 Server Error: Internal Server Error ("rpc error: code = 2 desc = "oci runtime error: exit status 1"") Info 2017/02/19 17:38:24 Container admin Start to do background task (create, wine-1)

Whenever I try to start the container, it throws the same error.
Any idea What I'm doing wrong?

[suchja]

Sorry for the Late response! I guess other containers are running without problems?

[suchja]

What exactly do you mean by installing? Please post the commands you enter to get error message.

[oywino]

Yes, all my other containers are running without problems.
I guess perhaps "installing" is not the right word. "Running" or "Starting" the container is perhaps better.
Every time I try to run the Wine container I just get the above error message and the container terminates.
I have tried all different version of Wine, and they all behave the same way.

[suchja]

Okay, could you please post the exact commands you are using to start the container? So far I cannot reproduce your problem.

[oywino]

Well, the thing is - I don't. Meaning - QNAP OS (Named QTS) has a docker front en named "Container Station". And for each loaded container, there are buttons for Install, Start, Stop and Remove.
What actually goes on under the hood, is beyond me, but I've never before had any problems getting containers to run. All I could find is that the Run command is listed as ; /entrypoint.sh

[suchja]

Okay! That’s beyond my knowledge! I’ve never used QNAP OS and the “Container Station”. Are there any Log-Files you can see? Probably somewhere (e.g. in the log-files) you can see what commands will be issued by “Container Station” to start the container. Unless you find that it is not possible for me to further investigate. Obviously it is a problem of the combination of my image and QNAP OS. However, the image is running without any problems on a “default” docker installation. I’m really sorry to be of no further help for you.

…

On 24 Feb 2017, at 15:50, oywino ***@***.***> wrote: Well, the thing is - I don't. Meaning - QNAP OS (Named QTS) has a docker front en named "Container Station". And for each loaded container, there are buttons for Install, Start, Stop and Remove. What actually goes on under the hood, is beyond me, but I've never before had any problems getting containers to run. All I could find is that the Run command is listed as ; /entrypoint.sh — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADexScyhiWImqU_21XHlxznOjcsImW4Tks5rfu5CgaJpZM4MFhOU>.

[oywino]

Not to worry, I'm pleased you even bother to reply :-)
When I issue the command:
docker run -d --name display -e VNC_PASSWORD=newPW -p 5900:5900 suchja/x11server
Docker complains that the name "display" is already in use. So every time I want to run the x11server using this command, I first have to manually remove (delete) the container name "display". Surely, this cannot have been your intention?
Secondly (assuming I successfully made the "display" container run), when I issue the command:
docker run --rm -it --link display:xserver --volumes-from display suchja/wine:latest /bin/bash
It doesn't run the version of Wine that I carefully downloaded and initialized (configured) according to my liking. No, it pulls a different version from the repo, gives it a funny name and configures it in a way useless for my applications. It runs, and I can launch explorer and notepad, but as long as I can't figure out a way to use 'my' Wine container (made from your Wine image) that I prepared to use a bridged network, have access to shares outside of the container etc. I'm not really in business. And I need a setup that I can start and stop at will, without the need to manually remove containers every time.

[suchja]

The x11server is running as a detached container. See docker documentation for more information. Basically the idea is that the server should continue to run and listen for connections and not immediately stop if it realises that currently no one likes to connect to it.

Now to the second part: I'm not sure what exactly you mean with:

It doesn't run the version of Wine that I carefully downloaded and initialized (configured) according to my liking.

Maybe I misunderstand your comment or the idea of this image is not completely clear to you. The image contains a version of wine which generally speaking can be changed, but it is not intended to change.
If the version in the image is not of your liking, you should consider creating your own image with the appropriate version you need. For this you need to create your own Dockerfile and use the appropriate versions in it. This is a little of try and error, but you can use my files in this repository as a starting point.

Which version do you like to run?

[oywino]

I'm sorry for being a bit clumsy here. I understand that the "display" (x11server) is supposed to run at all times. Which is quite all right, except - every time (now and then) when the server is rebooted, I don't know how to get the x11server started again (in an automated way).
Anyway, as you probably realized several posts ago, I'm a container newbie. I finally managed to get "outside access" from within Wine by modifying the startup command of the x11server like this:
docker run -d -v /share/Public:/mnt/Public --name display -e VNC_PASSWORD=newPW -p 5900:5900 suchja/x11server
That - at least, gave me a way to peek out into a share, thus having a way to bring data in and out of the container.
But I haven't (yet) been able to figure out how to get bridged network access to the rest of my LAN from within Wine. And that's what I meant when I (quite clumsy) used the word version. I'm not really referring to a different version of the image. What I did, was to download the your latest image, and configured it exactly as I wanted it to run. But I failed to figure out ho to modify your "docker run" command line to have it run my prepared "version" of your image instead of downloading a fresh copy from the repo each time.
So, the result I have right now, is a Wine that evaporates each time it exits (for whatever reason). The next time I run it, I have to reinstall and configure the same windows app(s) over and over again. I'm sure I do something wrong, cause I cannot imagine this to be intentional (from your hand), but I don't know what I'm doing wrong.
(I'll accept to be told to go away, if you feel this is a waste of your time)

[suchja]

No worries! I'm happy to support you as much as I can. I've been through this stuff with Docker and wine and know how hard it is when you are just starting.

With respect to the automated way of starting the x11server I think it is best to have a look into docker-compose. I don't know how it works with your QTS, but it is generally meant to automate multi-container applications.

If I understand you correctly, this is a high level overview of the workflow you are currently applying:

• Using docker run to start a container based on my image suchja/wine:latest.
• When the container is started you install windows apps and further configure wine
• Now you leave the container (probably by typing exit in the container's bash or stopping it via your frontend) for this session and would like to use it at this point in your next session
• Finally when you start again (with docker run and suchja/wine:latest) everything is gone and you need to start from scratch

If this is your problem, you need to have a look into the docker documentation for docker start and docker ls. In the readme of this wine image I've shown you this command docker run --rm -it --link display:xserver --volumes-from display suchja/wine:latest /bin/bash to start the container based on the image. If you look carefully, it has the option --rm specified. This means that the creates container is removed once you exit it and it gets stopped.

So basically what you need to do is to remove the --rm option from docker run command. Then you can install windows apps in the created container. Once you exit the container it will be stopped, but not removed! Now you can use docker ls to get the name or id of the stopped container and can use it with docker start to "restart" the container from where you left it the last time.

Does it make sense?

[oywino]

Do you have any plans to release a Wine 2.0 version. I'm asking, because once I got latest running, I found that none of the apps I need to run, would actually run. Very few programs support WinXP anymore. So I keep getting error messages during my install attempt saying that my version of Windows (Wine) is not supported, please upgrade.

[suchja]

So does that mean it is finally running on your side?

Update to wine 2.0 would be great, but there is currently no time on my side. If you actually like to test it, I might be able to create a new image.

[oywino]

Yes, it is running - allthough not exactly as I want it to, but I'll get there in the end.
I'd love to test a 2.0 image - if I may (or perhaps even 2.2 which I understand now is out in beta)

[suchja]

Will come back to you once the image is available!