Program 'works' in VM but not CT

[helojunkie]

Ombi is a request program that allows users to request TV and Movies on your Plex server.

So I have installed Ombi in a Ubuntu 16 (and 17) container. I can not get it to work and worked with the Ombi folks and finally determined that it will not work in a container for some reason. When I install a Ubuntu 16.04 VM and install Ombi, it works just fine, but not in a container.

It ***RUNS*** just fine, it just does not talk properly to the Plex server, even when loaded directly into the Plex server container.

I assumed that this has something to do with AppArmor but other than looking in dmesg (and finding a ton of apparmor DENIED messages, I can't seen to determine how Ombi is triggering AppArmor or how to fix it. SO I decided to disable apparmor to test it:

I added:

lxc.aa_profile: unconfined

to my conf file and restarted my container. I then got the PID of Ombi:

root@phxprox:~# ps aux | grep Ombi
111      16179 13.7  0.3 40011180 396080 ?     SLsl 19:19   0:15 /opt/Ombi/Ombi

and verified that it was unconfined:

root@phxprox:~# cat /proc/16179/attr/current 
unconfined

Yet it still does not work.

So now I am at a loss as to what to try next to troubleshoot the problem. I would hate to run an entire VM just for this one very small (but needed) application.

Thank You

 

[manu]

how are those two programms ( ombi and plex ) suppose to interact with each other ? via TCP/IP ?
if yes then I would start tcpdump on the listening port of plex since I suppose this is the server and ombi the client, to see if there is any traffic coming

tcpdump -i my_container_interface port my_plex_port

where my_container_interface is either eth0 or lo depending on which interfaces you configured plex to bind to

(NB: not sure if this is really a container problem here)

 

[helojunkie]

Thank You Manu - I will give this a try....

As for it not being a container problem, the problem **ONLY** happens when Ombi is installed in a container. The minute I install it in a VM it works instantly! To me that makes it a pretty safe bet that the problem is related (somehow) to how the containers work, otherwise the result would be the same (I would think) regardless of VM or CT.

 

[helojunkie]

OK, so I ran a tcpdumps and I can see the request go out to the Plex server and get returned to the container in question (now two separate containers). It appears that the request and reply are properly formatted. Ombi and Plex communicate via http (or https) with each other on Plex's port of 32400. In this case since all traffic is internal, we use http.

However, Ombi is still failing to operate while installed in a container while it runs absolutely fine when installed as a VM (same OS in CT and VM - Ubuntu 16.04).

I have replicated this problem on three different Proxmox servers and using three different Plex servers that I run. In EVERY CASE Ombi only fails when run from a container. However with the identical configuration on a Proxmox hosted VM, it runs perfectly.

I am not a Proxmox expert, but to me, this points to something in LXC.

Ombi does use dotnet-core (used to run mono) so I do not know if that has anything to do with it. Also, both containers are running unconfined right now.

Just looking for ideas as to the next step to figure this out.

Thank You

 

[manu]

without a debug trace of your program, it will be difficult of going any further
does the error that you see in the kernel log relate to your programm ?


I am aware of programm which does not run properly in unprivileged container when try to create devices nodes /dev or execute mounts, but I am not aware of normal user programms which do not run in a unconfined container

is your programm trying to access special hardware ? does it require device pass through to run ?

 

[helojunkie]

I don't see any errors from Apparmor. None of the DENIED messages has the PID of the program (Ombi). Also, I had (assumed) that by adding:

lxc.aa_profile: unconfined

in my config files that it disabled AppArmor completely, is this not the case?

So at that point whatever is happening is not related to Apparmor itself but something else under LXC.

The only thing the program does is to listen and talk on port 80 via http and to talk to an sqlite database.

 

[helojunkie]

Actually he said he is using Hangfire to handle all of the sqlite stuff...