Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Robad]

Yes I have read it.  But I still can't get it to work. 

I have tried port-forwarding on port 52199 to the Container IP (192.168.1.236) and to the QNAP IP (192.168.1.250).  (Though not at the same time...)  Both allow me to access the MC26 UI from my PC's browser at http://192.168.1.236:5800/.

I'm obviously using an "Access Key", so why would I care what my external IP address is??

"This key is automatically generated by JRiver's servers. It is associated with two IP addresses. One is for your server, as seen from inside your network (local), and the other is your outside address (Internet)."

Mind you, I'm intrigued as to how MC26 tells me what the Access Key is if the access test fails, presumably meaning JRiver's servers can't access MC26...

[BryanC]

Use host networking mode until you can get that sorted out. You've got too many variables in play right now for people to help you without just shooting in the dark.

To re-state:

1. You need to enable port forwarding on your gateway device (router) from port 52199 to port 52199 to...

• In network host mode, you would forward to your device IP
• In network bridge mode, you would forward to the container IP

Host mode is easier to diagnose because bridge mode requires a bunch of security contexts that are OS-dependent (e.g.):

By default, traffic from containers connected to the default bridge network is not forwarded to the outside world. To enable forwarding, you need to change two settings. These are not Docker commands and they affect the Docker host’s kernel.

    Configure the Linux kernel to allow IP forwarding.

    $ sysctl net.ipv4.conf.all.forwarding=1

    Change the policy for the iptables FORWARD policy from DROP to ACCEPT.

    $ sudo iptables -P FORWARD ACCEPT

I'm not familiar with QNAP software, so I don't know how they handle this.
Either way, you will need to assign a manual IP address to the appropriate container/device by MAC so that port forwarding will work.

2. In host mode you will need to use the software firewall port on your device to allow port TCP/52199. Again, I don't know if QNAP handles this automatically or not.

[Robad]

Thanks for the reply.

When I change the container network mode to "Host" I get the following:

"The port may conflict with the NAS port when selecting Host mode.
Use local host network (command: --net=host)
Note：This option allows containers to have full access to the host network interface."

I have no idea what this bit means: "Use local host network (command: --net=host)"

The operation fails with this:

"Failed to apply container settings.
Error Code: 500
Message: 400 Client Error: Bad Request ("conflicting options: mac-address and the network mode")"

[BryanC]

Thanks for the reply.

When I change the container network mode to "Host" I get the following:

"The port may conflict with the NAS port when selecting Host mode.
Use local host network (command: --net=host)
Note：This option allows containers to have full access to the host network interface."

I have no idea what this bit means: "Use local host network (command: --net=host)"

The operation fails with this:

"Failed to apply container settings.
Error Code: 500
Message: 400 Client Error: Bad Request ("conflicting options: mac-address and the network mode")"

This is sounding a lot like a question for QNAP. --net=host is just a docker command line option to enable host networking mode for the container. Presumably QNAP would stop and restart the container with the new settings, but maybe it needs it to be configured at runtime.

Perhaps try disabling the container before changing these settings, or you may need to recreate the container with fresh settings. It sounds like the functionality to dynamically change the network mode exposed by the QNAP software is broken (or maybe this is featured in their docs).

[Robad]

I think I'm going to give up.  I've tried everything I can think of, including:
- Changing network mode to 'Host'
- Changing back to NAT (as I had to create the container as 'NAT', this being the only way to specify a MAC address).
- Changing back to 'Bridge' with same IP as QNAP.
- I even searched for a container configuration file (and failed to find it)...  It would be so much easier to edit such a file, if it exists.

Everything either has no effect or makes it worse, leaving me to work out how to recover.

 

[BryanC]

I think I'm going to give up.  I've tried everything I can think of, including:
- Changing network mode to 'Host'
- Changing back to NAT (as I had to create the container as 'NAT', this being the only way to specify a MAC address).
- Changing back to 'Bridge' with same IP as QNAP.
- I even searched for a container configuration file (and failed to find it)...  It would be so much easier to edit such a file, if it exists.

Everything either has no effect or makes it worse, leaving me to work out how to recover.

 

This is definitely a QNAP support problem. The containers work fine running in Debian and CentOS on my end. I have no familiarity with QNAP, but I would suggest that if it is possible to just run the containers from the command line using the Docker executable.

Code: [Select]

docker run -d \
    --name=jrivermc26 \
    --net=bridge \
    --restart=always \
    --mac-address=ed:e8:60:2d:65:c1 \
    -p 5800:5800 \
    -p 5900:5900 \
    -p 52199:52199 \
    -p 52101:52101 \
    -p 52100:52100 \
    -p 1900:1900/udp \
    -v config:/config:rw \
    -v /path/to/music:/data/music:rw \
    -e VNC_PASSWORD=12345 \
    shiomax/jrivermc26
It seems that whatever software they have built on top of Docker is broken.

[Scobie]

My main setup is MC26 running on the QNAP Container Station, and can access from the internet using this config:

Network Mode: Bridge
Use Interface: Adapter 1( Virtual Switch 1)
Static IP (on local network)
Assigned Mac Address (can be anything)

On my router
Forward 52199 to the Static Container Address on TCP/UDP

[Robad]

My main setup is MC26 running on the QNAP Container Station, and can access from the internet using this config:

Network Mode: Bridge
Use Interface: Adapter 1( Virtual Switch 1)
Static IP (on local network)
Assigned Mac Address (can be anything)

On my router
Forward 52199 to the Static Container Address on TCP/UDP

There are only 2 differences on my system:
- "TCP" not "TCP/UDP".  I have changed this and it made no difference...
- I'm using "Virtual Switch 3" - probably due to previous attempts.  The other 2 are not associated with a physical adapter.

"Virtual Switch 3" has the (static) IP address of the QNAP NAS.

[Robad]

You're not going to believe this...

I just tried connecting from my phone.  The Access Key has been changed so I edited the server in JRemote.  I noticed that there was a field for "Global IP", which was close to the IP address from 'www.whatsmyip.org'.  So I edited it to make it the same.  I then disabled wifi on the phone and succeeded in connecting!

I have no idea of the relevance of this.  Maybe next time I'm allocated a different external IP address it will stop working (despite the Access Key claiming to cope with this).

Test still fails though...

[Scobie]

If at all possible try and get a static IP from your ISP, it makes external access a lot easier, but it does look like your MC/Container setup is correct given that it did work.

Even so, I think I'm right in saying - happy to be corrected - that as long as your external IP is accessible (i.e. not double NAT'd or something) then if the key is correct JRemote should be able to maintain the correct address.

[max096]

Thanks for the reply.

When I change the container network mode to "Host" I get the following:

"The port may conflict with the NAS port when selecting Host mode.
Use local host network (command: --net=host)
Note：This option allows containers to have full access to the host network interface."

I have no idea what this bit means: "Use local host network (command: --net=host)"

The operation fails with this:

"Failed to apply container settings.
Error Code: 500
Message: 400 Client Error: Bad Request ("conflicting options: mac-address and the network mode")"

The error makes sence. When you use host networking you are using your hosts network interface. You cannot just reconfigure its mac address from a docker command and thatīs a good thing. So donīt use the mac address option with host networking. The only reason I included the mac address in the bridge config is because otherwise your mac address will change when you teardown and recreate the container (in case of updating it) and then you would have to re-activate jriver every time. Bridge networking means youll create an isolated virtual network for every (although possible to configure one for multiple) container(s) you create.

[HaWi]

Hi all
I'm a total rookie in Docker but I would like to set up a MC26 Docker container on my Synology 1819+. I got as as far as being able to log into it with JRemote but it doesn't see the media files. I have them located in /music right on volume1.
I also created a symlink to that folder in /docker/config/music. I tried either
-v /volume1/docker/config/music:/music:rw \    or
-v /volume1/music:/music:rw \
to no avail
Could someone please explain to me how to get the correct path to my media?
many thanks
Hans
PS: this is what I used to start up (with the correct Key, of course):

sudo docker run -d \
    --name=jrivermc26 \
    --net=host \
    --restart=always \
    -v config:/config:rw \
    -v /volume1/docker/config/music:/music:rw \  or -v /docker/config/music:/music:rw \
    -e VNC_PASSWORD=XXXXX \
    shiomax/jrivermc26

[max096]

-v /volume1/docker/config/music:/music:rw

The left path /volume1/docker/config/music is the path on your actual machine to your music and /music is where you would find them inside the container. You can put your music wherever you want. In the examples I suggested /data/music, but if you prefer /music that's perfectly fine. You can set the folder to effectively anything you want. But the right path is where it's going to end up at. Since you set it to /music that's where /volume1/docker/config/music is going to be inside your container.

[HaWi]

Thanks max!
In the container terminal I can see the media in the /data/music folder (after understanding that this is the container internal folder for the media, I changed to /data/music as you suggested). However, when I connect to the server with JRemote, there are no media. Could it be a permissions issue? How would I change those permissions?
EDIT: When I try to set up file location in MC26 on the Synology, I get an error (see attached). How can I get this fixed?
 
many thanks,
Hans

[max096]

Thanks max!
In the container terminal I can see the media in the /data/music folder (after understanding that this is the container internal folder for the media, I changed to /data/music as you suggested). However, when I connect to the server with JRemote, there are no media. Could it be a permissions issue? How would I change those permissions?
EDIT: When I try to set up file location in MC26 on the Synology, I get an error (see attached). How can I get this fixed?
 
many thanks,
Hans

Try this.
On your NAS run

Code: [Select]

ls -la /volume1/docker/config/music

See what user and group the folder belongs to.

Look up the numeric userid and groupid of those (id user).

Then similarly to how you set the VNC_PASSWORD environment variable you are gonna set USER_ID to the numeric user id and GROUP_ID to the group id.

[HaWi]

Great, thank you so much max, I'll try that!
Best wishes,

Hans

[HaWi]

Well, both UserI and GroupID are 1000 which, I take it, is administrators. I set the variables to that but still the MC26 docker container cannot get access to the media. My user ID has all the privileges, too but when I set the user ID to mine, I cannot even open MC in the Browser on port 5800. Is there any other way?
many thanks,
Hans

EDIT: I finally figured out how to get access to the Media. Turns out that I had the UID and GID wrong. Using the id command in the terminal I found out the correct IDs for the owners, which I changed previously. Trying to import the into the library now...
Thanks so much for your help! I learned a lot about Linux and CLI, btw.
EDIT2: It's all working now. I restored a backup of my iMac library into the Docker MC26, changed the file location on all tracks and it's working as brilliantly as on the iMac, JRemote works as well. I am very happy.
EDIT3: Thank you so much again for creating this image. You are a star!
cheers,
Hans

[max096]

Well, both UserI and GroupID are 1000 which, I take it, is administrators. I set the variables to that but still the MC26 docker container cannot get access to the media. My user ID has all the privileges, too but when I set the user ID to mine, I cannot even open MC in the Browser on port 5800. Is there any other way?
many thanks,
Hans

EDIT: I finally figured out how to get access to the Media. Turns out that I had the UID and GID wrong. Using the id command in the terminal I found out the correct IDs for the owners, which I changed previously. Trying to import the into the library now...
Thanks so much for your help! I learned a lot about Linux and CLI, btw.
EDIT2: It's all working now. I restored a backup of my iMac library into the Docker MC26, changed the file location on all tracks and it's working as brilliantly as on the iMac, JRemote works as well. I am very happy.
EDIT3: Thank you so much again for creating this image. You are a star!
cheers,
Hans

No problem. 

1000 is the default value of those two variables in the image and in any generic Linux distro I know off the id of the first user you create.

[HaWi]

Thanks for the info, I didn't know that.
Can I ask another question?
I now have two identical libraries running. The original one on the iMac and the restored backup of it in the Synology/Docker Container. I would like to use the Mac for maintaining the library and the Docker Container to actually serve up the music so I don't need to run my Mac all the time, especially when I am away from home (The NAS is running 24/7).
Is there a way to keep the libraries synchronized without having the Mac on all the time or is there a way to only use one library?
Many thanks,
Hans

[max096]

Thanks for the info, I didn't know that.
Can I ask another question?
I now have two identical libraries running. The original one on the iMac and the restored backup of it in the Synology/Docker Container. I would like to use the Mac for maintaining the library and the Docker Container to actually serve up the music so I don't need to run my Mac all the time, especially when I am away from home (The NAS is running 24/7).
Is there a way to keep the libraries synchronized without having the Mac on all the time or is there a way to only use one library?
Many thanks,
Hans

With JRiver media network features you can connect to another jriver library in your network and stream the music from there. Activate the media network in the settings in jriver on your NAS, put a password if you want one. Then you can connect to it from any other JRiver instance by adding it as a new library.

[HaWi]

Thank you max!
Does that mean I don't have to have the Mac running and can still stream from the Mac library. That almost sounds too good to be true.
cheers,
Hans
EDIT: Looks like I cannot access the Mac library from the Docker Container and neither can I access the Docker Container library from the Mac MC26 (it's in the .jriver folder that's invisible in samba on my Mac). I there a way around this?
EDIT2: I found a potential solution: I cloned the Docker MC26 library into a new share, also mounted from Docker. Then, I load that library from MC26 on my iMac and point all tracks it to the correct path from the iMac. It works although it's a little slow on the Mac. I'm OK with that for now but please, let me know if you can think of a better solution.
many thanks,
Hans

[max096]

Thank you max!
Does that mean I don't have to have the Mac running and can still stream from the Mac library. That almost sounds too good to be true.
cheers,
Hans
EDIT: Looks like I cannot access the Mac library from the Docker Container and neither can I access the Docker Container library from the Mac MC26 (it's in the .jriver folder that's invisible in samba on my Mac). I there a way around this?

You just want to not have a local library on your mac (put everything on your nas). You add a new library on your MAC and type in the ip of your NAS/Docker container. You need to enable media network on the NAS jriver instance but I think you already did that given you connected to it with jremote. Same concept you just connect to it with jriver.

The only upside to a "sync" type of solution would be that if you have a notebook. You could then take it with you and still have your media even if you donīt have access to your NAS (not sure if thatīs entierly possible though). But if we are talking about a desktop iMAC I really do not see the point on why it would be necessary to connect from anything to your iMAC except for remote controlling what your iMAC plays right now. And for that it needs to be on either way or it wonīt play music.

[HaWi]

Thanks max!

[HaWi]

I recently looked at the log in the MC26 Docker Container and discovered that there are multiple (>1500) attempts to access the container from the Internet. They all have different IP addresses but trace back to vmixxxxxx.contaboserver.net (xxxxxx is a different number in each case) in Germany. I have set a Firewall rule on my DS1819+ to deny all access from Germany but it is still happening. I have attached a sample screenshot from the log.
Is there any way I can prevent this in the future?
Many thanks,
Hans

[bob]

I recently looked at the log in the MC26 Docker Container and discovered that there are multiple (>1500) attempts to access the container from the Internet. They all have different IP addresses but trace back to vmixxxxxx.contaboserver.net (xxxxxx is a different number in each case) in Germany. I have set a Firewall rule on my DS1819+ to deny all access from Germany but it is still happening. I have attached a sample screenshot from the log.
Is there any way I can prevent this in the future?
Many thanks,
Hans

I have no idea why you are seeing that but if the docker container ethernet interface is running in bridged mode you can't block it by changing the firewall on the device it's running on (the DS1819+ I assume) .
You could run a firewall in the container or block it on your outside router.
I'm suspicious that you are seeing response packets to something originating from within the container itself.

[max096]

That's the log from x11vnc. Does not look like he guessed your password though. But also does not look like your firewall rules are working if you are still getting that after you applied them.

One thing you can do in the container is enable secure connection. That will enable https and ssl in vnc. Ofc it wont really solve the problem of it being world viewable if you make it public. If you dont need to access vnc when not at home then don't foward 5800 and 5900 from your router to your NAS.

Id recommend looking into setting up a VPN to you home network and don't expose any ports of any services otherwise. The less gates you open the less you are gonna get annoyed by them.

Another good way to do it if you need public accessability without a VPN would be haproxy. Ive not looked into it that much yet. But Ive seen this https://forum.level1techs.com/t/haproxy-wi-run-lots-of-public-services-on-your-home-server/159335 recently. Looked very interesting.

[max096]

I have no idea why you are seeing that but if the docker container ethernet interface is running in bridged mode you can't block it by changing the firewall on the device it's running on (the DS1819+ I assume) .
You could run a firewall in the container or block it on your outside router.
I'm suspicious that you are seeing response packets to something originating from within the container itself.

Not sure how you come to the conclusion that a connection is established from within the container to the outside?

[bob]

Not sure how you come to the conclusion that a connection is established from within the container to the outside?

It's not a conclusion, just a guess since he wasn't able to block the address.
I really didn't know why he'd be getting incoming to a container, I wasn't aware that he'd enabled VNC to the NAS.

[max096]

It's not a conclusion, just a guess since he wasn't able to block the address.
I really didn't know why he'd be getting incoming to a container, I wasn't aware that he'd enabled VNC to the NAS.

The VNC stuff is all in the container. Since JRiver requires a GUI you kinda sorta have to access it somehow. I dont really want a full blown DE on my servers so that was one of the main reason I even turned to docker for that.

Public accessability and security are always a bit tricky. I would also imagine if bots find a VNC server they would try to tackle it since to me anyways requiering remote desktop on your server would lead me to believe you are an easier target to be hacked. That hacker gonna be pretty disappointed when all he sees is JRiver. ^^

[bob]

Great, thanks for the explanation.

[HaWi]

I have no idea why you are seeing that but if the docker container ethernet interface is running in bridged mode you can't block it by changing the firewall on the device it's running on (the DS1819+ I assume) .
You could run a firewall in the container or block it on your outside router.
I'm suspicious that you are seeing response packets to something originating from within the container itself.

Thanks Bob, I am running it in host mode, though.

[HaWi]

That's the log from x11vnc. Does not look like he guessed your password though. But also does not look like your firewall rules are working if you are still getting that after you applied them.

One thing you can do in the container is enable secure connection. That will enable https and ssl in vnc. Ofc it wont really solve the problem of it being world viewable if you make it public. If you dont need to access vnc when not at home then don't foward 5800 and 5900 from your router to your NAS.

Id recommend looking into setting up a VPN to you home network and don't expose any ports of any services otherwise. The less gates you open the less you are gonna get annoyed by them.

Another good way to do it if you need public accessability without a VPN would be haproxy. Ive not looked into it that much yet. But Ive seen this https://forum.level1techs.com/t/haproxy-wi-run-lots-of-public-services-on-your-home-server/159335 recently. Looked very interesting.

Thanks max,
I am running in host mode, so the firewall should work but maybe that's a Synology issue (i'll check again). The reason why I moved MC to Docker was so that I can access it from outside the LAN and have it running 24/7.
What worries me is that due to the restriction to 6  characters for the password, eventually one of them is guessing the right one. I will look into VPN or haproxy which was my plan anyway (that's going to annoy my wife and kids  ). I am just such a dud when it comes to networks.

cheers,
Hans

[max096]

Thanks max,
What worries me is that due to the restriction to 6  characters for the password, eventually one of them is guessing the right one. I will look into VPN or haproxy which was my plan anyway (that's going to annoy my wife and kids  ). I am just such a dud when it comes to networks.

There is no restriction to have 6 characters as your VNC password. Mine is longer than that.

[HaWi]

Thanks max,
I am running in host mode, so the firewall should work but maybe that's a Synology issue (i'll check again). The reason why I moved MC to Docker was so that I can access it from outside the LAN and have it running 24/7.
What worries me is that due to the restriction to 6  characters for the password, eventually one of them is guessing the right one. I will look into VPN or haproxy which was my plan anyway (that's going to annoy my wife and kids  ). I am just such a dud when it comes to networks.

cheers,
Hans

I looked into my settings again and I set a IPv6 firewall rule on my Eero gateway to block all the MC ports from IPv6 and now, it seems that the attacks are being quashed. Fingers crossed.
EDIT: Spoke too soon, the attacks slowed down a bit but still coming...

[max096]

I looked into my settings again and I set a IPv6 firewall rule on my Eero gateway to block all the MC ports from IPv6 and now, it seems that the attacks are being quashed. Fingers crossed.
EDIT: Spoke too soon, the attacks slowed down a bit but still coming...

How did you block germany as a country? Can you lookup what IPs are on that list your router is using? Try to instead block specific IPs, or ranges. If your router has a country based blocking system it might very well be spotty. The only way that I can tell to find out where an IP is coming from is to ask external services that supposedly know it, because they built databases mapping it based on what IPs belong to what ISP (currently, hopefully). But threw the actual connection there is not really anything you can trust that I know of to really tell where the IP is coming from.

[HaWi]

How did you block germany as a country?

I am using the Synology Firewall, there you can select Countries but, as you say, that might be spotty.

Can you lookup what IPs are on that list your router is using? Try to instead block specific IPs, or ranges. If your router has a country based blocking system it might very well be spotty. The only way that I can tell to find out where an IP is coming from is to ask external services that supposedly know it, because they built databases mapping it based on what IPs belong to what ISP (currently, hopefully). But threw the actual connection there is not really anything you can trust that I know of to really tell where the IP is coming from.

I have also blocked ranges of IP's but there have been >1500 IPs so far ... And I blocked myself a few times, too 
I ran  Traceroute in Network Utilities on my Mac, and the penultimate server often shows a domain name, like a provider (Telstra, in Sweden comes up often, too), so I am only guessing. I have set up a quick and dirty OpenVPN server on the Synology but am unclear if I should now remove all Port fwds from my Router, which is a Eero, and makes it very painful to reopen them. If I do it, do I need to open the ports through VPN? I am a total noob, I'm afraid.

[Scobie]

Would it be worth destroying the Container and redownloading the image?

May be that you've been hacked so best thing is just to kill it and redeploy...?

[HaWi]

Would it be worth destroying the Container and redownloading the image?

May be that you've been hacked so best thing is just to kill it and redeploy...?

I don't think I have been hacked. All the attempts failed at authentication.

[HaWi]

I am running into a problem now that when I activate the firewall, I cannot open MC26 on port 5800 anymore. I have a rule opening it, though. I also open all the other ports that I thought I needed, like 5900, 51000, 51101, 52199, 52000. Are there any ports I am missing?  The problem goes away when I disable the final Deny All rule.
Many thanks,
Hans
EDIT: I think I figured it out. Some ports were UDP and needed to be TCP...

[max096]

I am running into a problem now that when I activate the firewall, I cannot open MC26 on port 5800 anymore. I have a rule opening it, though. I also open all the other ports that I thought I needed, like 5900, 51000, 51101, 52199, 52000. Are there any ports I am missing?  The problem goes away when I disable the final Deny All rule.
Many thanks,
Hans

You just need 52199 to be able to connect to it with JRiver and JRemote etc. 5900 or 5800 for VNC if you need it. Have you tried to enable SECURE_CONNECTION? You can read up more here https://github.com/jlesage/docker-baseimage-gui#security. Id recommend it either way if you do want to host it in a public manner. It might also have the unintended side effect of breaking whatever VNC client they are using, because SSL over VNC is very much not a standard feature at all. You are very restricted in what VNC client you are able to use with it. A lot of them donīt work with it at all. Just use one that works yourself.

About your firewall rules. I canīt really help you with that either as Im not very familiar with synology NAS. Im sure there are many resources out there as itīs very popular NAS solution. I do however think that blocking all people that ever try to access it is a real rats nest to get into especially if you are getting thouthands of requests already. IPs are very easy to come by these days with all the AWS of the world that allow you to just spin up things anywhere around the globe on demand. I would say keep the container up to date (at least once every monthsīish) with a secure enough password you should not have problems with it. Make backups of your config and music directory and they wonīt even be able to do any considerable damage when they get it right.

If you can manage also try to use a different public port other than 5900 (or use the 5800 web ui, should also be better). As 5900 is the default VNC port it is what people would look for. Just pick something like 8083 you will likely see far less access on it. If you cannot do it on your router like this for some reason I think you can also change it with the -rfbport option. I however never tried this and am not sure if the webui would still work when the VNC port has changed inside the container.

Just to give you an idea how many possible combinations there are in passwords to make you a bit more comfortable about your thouthands of requests. There are 26 letters in the alphapet. Lets just say we restrict ourselves to only lower case letter and 10 of them. That would mean you have 26! / (26-10)! options which if you type it into google (well... calculator on the go lul) it spits out 1.9275224e+13 possible combinations, so appearently google decides 19275224000000 is too big for the calculator already to display (e+13 means * (10^13)). You can play this game with bigger sets of possible characters and/or longer passwords. You will find that you very quickly reach a number that is unimaginable big in human terms. Meaning if your password is secure enough you probably cannot brute force it. They would need some exploit or social engineering to skip or get the password. They still try anyways as there are a lot of machines out there that run unsecure passwords you would find in common password lists, or combinations of those lists. Or itīs a well known default password from products that automatically configure VNC.

[HaWi]

Thanks Max! This is very helpful. With my latest changes to the firewall and closing all unnecessary ports on my router, I haven't seen a single attempt coming through for >24 hours.
EDIT: I realized that I could NOT fwd ports 5800/5900 and still get local access to the UI via a browser which is all I need.
I will look into SECURE_CONNECTION, as long as it doesn't break JRemote access, as this is the only app I use to access the library remotely.
In case I wanted to change the default VNC ports I know how to forward them from my router but I am unsure how to tell the container since I am running in host mode. Would I have to switch to bridge mode? Or could I just change the remote port and fwd to 5800, for example.
Your are right, of course, the number of combinations is huge, even for 6 characters. JRiver assign a unique, random VNC password for every installation, so worries are unfounded. I also have 3-2-1 backups, so if anything nasty should happen, I should be OK.
Thank you so much again, Max, for giving us the opportunity to run MC on a NAS.
cheers,
Hans

[max096]

EDIT: I realized that I could NOT fwd ports 5800/5900 and still get local access to the UI via a browser which is all I need.
I will look into SECURE_CONNECTION, as long as it doesn't break JRemote access, as this is the only app I use to access the library remotely.

It does not impact MC in any way. VNC is just the remote desktop server running in the container. When you go to the website at :5800 thatīs the novnc webui (which is just a client for the VNC Server running on the web, so youīd see an access from 127.0.0.1 in the docker logs when you use the webui, no matter from where you do that). Otherwise, youīd use a program such as https://www.realvnc.com/en/connect/download/viewer/ or http://www.karlrunge.com/x11vnc/ssvnc.html and access the "desktop" that way using port 5900. If you donīt do that ever. You might as well block 5900 entierly.

About the SECURE_CONNECTION this itīs just another environment variable. Remember how you set the USER_ID thing. Do the same thing except this one is just on or off. So 1 would be on. When you access your browser it will then tell you "this is not a secure connection" (or something similar to that, ironically). This is because you created your own certificate (or the container did anyways on first startup with that flag). You are not an authorized certificate provider that sells certificates. So your certificate isnīt trusted automatically. Itīs used to make https work, so you actually have an encrypted connection. This is a lot better than not having https/ssl.

In case I wanted to change the default VNC ports I know how to forward them from my router but I am unsure how to tell the container since I am running in host mode. Would I have to switch to bridge mode? Or could I just change the remote port and fwd to 5800, for example.

What i was suggesting is to forward port 8083 on your router to port 5900 on your NAS. So, then if you where outside your local lan youd have to use :8083 for VNC instead of 5900 inside your Lan still 5900. It does not make the VNC server disappear entierly, but it does make it harder to discover.

Your are right, of course, the number of combinations is huge, even for 6 characters. JRiver assign a unique, random VNC password for every installation, so worries are unfounded. I also have 3-2-1 backups, so if anything nasty should happen, I should be OK.

Youīre probably talking about the 6 digigs access key in Media Center (now I also know where you got the idea from that there would be a limit for the lenghts...). Thatīs not your vnc password. Nobody tried to access media center in the PDF you sent. And nobody really wants to do that either (at least it would surprise me). They donīt know the "desktop" they are trying to get into is literally just media center without anything else running. It could be any machine, like a Windows desktop where you can encrypt random peoples harddrives and then send them emails to pay you xyz money so that you supposedly unencrypt it again (maybe). It all does not really apply here. This is bearly even a working desktop and the only program is MC. As I laid it out earlier whoever is or was trying to get into it would be very disappinted when he acutally sees whatīs there. A whole lot of nothing. If they wanted songs they could just pirate them it would be much easier than trying to get into random peoples media libraries.

[HaWi]

Thank you, Max!
Now I understand better how it works. I had no idea that the VNC Access Key is not the VNC password because the Access Key is what I plug in every time I open the UI on the browser. Also, I only need to access the webui locally so I have removed both 5800 and 5900 from my router.
One more question, to update the container, do I just download the latest image and then re-run the script I originally used to install the container or is there a way to just update from the new image?
cheers,
Hans

[max096]

One more question, to update the container, do I just download the latest image and then re-run the script I originally used to install the container or is there a way to just update from the new image?

Yes, thats how I would recommend you do it with this image.

Now I understand better how it works. I had no idea that the VNC Access Key is not the VNC password because the Access Key is what I plug in every time I open the UI on the browser. Also, I only need to access the webui locally so I have removed both 5800 and 5900 from my router.

Maybe I got lost here as well. The one you enter into the webui is indeed the vncpassword. But you also said that it is random for every media center installation and that itīs limited to 6 characters. Both of those things are not true for the vncpassword, but would be if you are talking about the access key media center creates. You defined the vncpassword when you created the container, you choose it with any lengths you want. The access key is this thing https://wiki.jriver.com/index.php/Access_Key and has nothing to do with VNC.

[HaWi]

Thanks Max, that makes sense. My faulty assumption was that the VNC password had to be the VNC Access Code, so that‘s what I put as the VNC password. Now I understand that I can put anything as the VNC password. I will change that, next time I update.

[Afrosheen]

I figured out what was wrong. In the start command of MC I set the home directory to /config and in the command I now entered I did not do that.

So this is how you can activate the container with the mjr file. First get the mjr file and place it into the config folder. I just named it key.mjr, because I copied it with scp and it was less to type. Also my container is named jrivermc26, yours might have a different name.

Code: [Select]

docker exec -it jrivermc26 /bin/bash
exec env HOME=/config mediacenter26 /RestoreFromFile /config/key.mjr

As I said I'm probably gonna just make this happen on startup when the config directory contains any file with the .mjr extension. But for now this works.

I have just pushed a new version of it. It looks for .mjr files within the config directory every 30 seconds. When it finds one it tries to activate jriver with it. If it's successful it get's rid of the .mjr file.

Hi, I hope this message receives you all well.  I'm having trouble with keeping the app licensed upon restarting my NAS.  Each time I restart I have to retype the license key before being able to use the app.  Instead of doing that, I'm trying to follow your method of just having the license key file stored in the "config" folder, but one wasn't created when I installed it via QNAP's Container Station app.  I've created a screenshot of the folder structure and have placed the file in every folder that seems reasonable, but no avail.  I'm not familiar with using the command line with QNAP's Container Station.  I appreciate the consideration.

[Scobie]

You can get around this issue by assigning a Mac address to the container. The license blows up because it is looking for the same Mac address it used before and when it doesnt find it it assumes it is running on a different host.

Doesn't have to be a accurate, just valid, and there are places online to generate one.

[max096]

Hi, I hope this message receives you all well.  I'm having trouble with keeping the app licensed upon restarting my NAS.  Each time I restart I have to retype the license key before being able to use the app.  Instead of doing that, I'm trying to follow your method of just having the license key file stored in the "config" folder, but one wasn't created when I installed it via QNAP's Container Station app.  I've created a screenshot of the folder structure and have placed the file in every folder that seems reasonable, but no avail.  I'm not familiar with using the command line with QNAP's Container Station.  I appreciate the consideration.

Was this resolved now? By the looks of it your _data folder is mounted to /config. Since the user chooses the path to mount it to the only way I can refer to it is "the config directory", in your case it means _data then.

The MJR file wonīt help you if your license key gets accepted. Itīs only a fallback way to activate if the license key does not work at all.

As @Scobie said you might have to specify a mac address for the license to stay activated (this is only neccessary when using bridge networking). If you do not need the ablity to remap ports I would recomend you use host networking, then you also do not need to specify a mac address as it uses your hosts network interface instead of generating a virtual one.

[Afrosheen]

Yes it’s resolved! Thank you!! I just rebuilt the container with a specified MAC address last night and then restarted and it opens without the splash screen!

I’ve had to build it with bridge networking because using the same LAN IP as the NAS itself makes things go haywire. Maybe I’m missing something but I just wanted to get a stable MC server running again.

Thanks again for the help @Scobie & @max096

[HaWi]

I’ve had to build it with bridge networking because using the same LAN IP as the NAS itself makes things go haywire. Maybe I’m missing something but I just wanted to get a stable MC server running again.

Strange, I am running MC in host mode on my Synology DS1891+ and, apart from all the rookie mistakes I made, I haven't had a problem. I activated MC in docker by using the MC27 master license .mjr key file through the WebUI. I do have to put in the Access Key every time I reload the UI on my browser, though.