[Support] ich777 - Application Dockers

[ich777]

12 minutes ago, lhw1221 said:

2. going superuser perr su

Did you enter only "su" or did you enter "su $USER" (without double quotes)?

 

For what container do you try to setup a VNC password?

 

[lhw1221]

13 minutes ago, ich777 said:

Did you enter only "su" or did you enter "su $USER" (without double quotes)?

 

For what container do you try to setup a VNC password?

 

 

ahh okay i was to stupid to follow the documentation properly THX
(i put su whithout $USER, whent automode)
 

[storhob21]

9 hours ago, ich777 said:

I have to look into this but this should no issue whatsoever.

Give me a bit since I'm currently fighting with a pretty bad cold...

sounds good, hope you feel better. Whenever you can look into it that be great, no rush on my part.

[ich777]

2 hours ago, storhob21 said:

sounds good, hope you feel better. Whenever you can look into it that be great, no rush on my part.

Please update the container, it should now work.

 

Also please set the password first as non root user as instructed in the recommended post and if that is working, or if it is already working for you with non root, then switch over to root.

[storhob21]

2 hours ago, ich777 said:

Please update the container, it should now work.

 

Also please set the password first as non root user as instructed in the recommended post and if that is working, or if it is already working for you with non root, then switch over to root.

works perfect now with root, thanks for the quick fix.

[TheBenga]

Hi,

 

Hoping someone can clarify something for me...

 

I've been playing around with PhotoPrism and am confident it's the tool for me. About to nuke my dev Docker and build afresh for full production. What I'm waning to set up:

 

-RO 'Originals' path (already exists as a HDD-based share)

-Cache-based 'Storage' (pair of 500Gb SSD -this exists and is stable, all existing dockers are here) 

-Separate 'Sidecar' path (separate HDD-based location - I have MANY HEIC photos which PhotoPrism will need to make a converted copy of and this repo needs to be off-cache but NOT in my 'Originals' folder)

 

Indeed, even better than the above would be to retain all 'sidecar' and 'storage' functions on cache with the exception of only the converted HEIC images on spinning disk in an alternative location but I suspect this may be a bit too much to ask... 🙂

 

Can anyone help clarify what paths in the Docker config I need to setup?

 

(my main problem is that depending on the where I look to learn, there are unclear uses of the terms 'original', 'sidecar' & 'storage')

 

Thanks if anyone can help!

[unxplained]

Hi,

 

I'm trying to set a password for the TURBOVNC, I referred to the recommended post but I am not running unraid, just regular docker + portainer. 

 

Is there a way to set up the password in the docker compose file instead?

 

Thanks

[ich777]

8 hours ago, TheBenga said:

(my main problem is that depending on the where I look to learn, there are unclear uses of the terms 'original', 'sidecar' & 'storage')

Can you please point me to the resources that you are referring to?

[ich777]

1 hour ago, unxplained said:

Is there a way to set up the password in the docker compose file instead?

Not the password but you can set it in your compose file at the "environments" create another entry that looks something like:

	environment:
		TURBOVNC_PARAMS: ""

 

Of course your other variables have to go there too like the UID, GID,...

Don't forget to first set the password like described in the recommended post in this thread on the top.

 

Where do you have issues, it should work just fine on Portainer too I think or do they not allow empty environment variables?

 

Hope that helps.

[unxplained]

44 minutes ago, ich777 said:

Not the password but you can set it in your compose file at the "environments" create another entry that looks something like:

	environment:
		TURBOVNC_PARAMS: ""

 

Of course your other variables have to go there too like the UID, GID,...

Don't forget to first set the password like described in the recommended post in this thread on the top.

 

Where do you have issues, it should work just fine on Portainer too I think or do they not allow empty environment variables?

 

Hope that helps.

Hello,

 

So these are my steps:

- Using docker compose, build the container (without turbovac_params)

- su $USER etc etc to create password

- go to container variable where turbovac_params is = -securitytypes none

- edit that parameter to be empty

- when the container recreates and replaced the previous one, turbovac_params is still securitytypes none

 

I also tried to add a testvar = {empty}, but when the container recreates, this variable doesn't exist

 

I assume this means portainer doesn't allow empty environment variables. 

 

If I were to set this up via command line, how would I go about doing it?

 

EDIT: error message in container's logs

/opt/scripts/start-server.sh: line 121: 76 Aborted (core dumped) ${DATA_DIR}/ferdi --no-sandbox --disable-accelerated-video --disable-gpu --dbus-stub 2> /dev/null

 

Thanks

 

 

 

Edited May 11, 2022 by unxplained

[ich777]

10 minutes ago, unxplained said:

I assume this means portainer doesn't allow empty environment variables. 

This is really odd...

 

15 minutes ago, unxplained said:

- go to container variable where turbovac_params is = -securitytypes none

Try to set the variable to:

-securitytypes VNC

 

and see if that helps.

[unxplained]

29 minutes ago, ich777 said:

This is really odd...

 

Try to set the variable to:

-securitytypes VNC

 

and see if that helps.

 

Hello, 

 

I got it!

 

Here's for reference if anyone needs.

 

version: '3.3'
services:
    ferdi-client:
        container_name: Ferdi-Client
        ports:
            - '8080:8080'
        environment:
            - UID=XXXX
            - GID=XXX
            - UMASK=0000
            - DATA_PERMS=770
            - TURBOVNC_PARAMS=-securitytypes VNC
        volumes:
            - '/your/folder:/ferdi'
        image: ich777/ferdi-client

 

And then set up the password as per recommended post

- su $USER

- vncpasswd

- enter password twice

 

Thanks!

Edited May 11, 2022 by unxplained

[ich777]

1 hour ago, unxplained said:

        image: ich777/ferdi-client

Are you actually using Ferdi-Client?

I've deprecated the container because the maintainer abandoned the project or is it back again?

 

I saw that it is back again, updated the container a bit and pushed it already to DockerHub and the GitHub container registry.

[storhob21]

@ich777 

One more thing I noticed and hopefully theres a fix for it. I run the container as root. The issue I'm having is each time I update the container, roots "Know_hosts" file in /root/.shh gets removed.
 

Is there any way root could reference luckybackup user's know_hosts file instead? I'll add the destination host ECDSA key there since that does not get removed when updating the container.

[ich777]

15 minutes ago, storhob21 said:

Is there any way root could reference luckybackup user's know_hosts file instead? I'll add the destination host ECDSA key there since that does not get removed when updating the container.

I would recommend that you copy the file over to /luckybackup/.shh with the command:

cp /root/.ssh/known_hosts /luckybackup/.ssh/known_hosts

 

...then it should hopefully work fine, but I can also remove this requirement so the container will connect to any host without asking.

 

Container updates also shouldn't happen too often by the way because my containers work slightly different, they check for updates from the application on container start.

[storhob21]

47 minutes ago, ich777 said:

I would recommend that you copy the file over to /luckybackup/.shh with the command:

cp /root/.ssh/known_hosts /luckybackup/.ssh/known_hosts

Thats what I've done but whenever I update the container root needs to trust my destination host again even though the host is in the /luckybackup/.ssh/known_hosts. No biggie, I'll just keep in mind each time I update to go in and trust my destination host with root.

[ich777]

2 hours ago, storhob21 said:

No biggie, I'll just keep in mind each time I update to go in and trust my destination host with root.

I will look into that and report back, maybe I can push a update tomorrow...

[ich777]

5 hours ago, storhob21 said:

No biggie

Should now be fixed, please update the container and report back.

[storhob21]

1 hour ago, ich777 said:

Should now be fixed, please update the container and report back.

Just updated and its fixed. Host gets added without a confirmation prompt after an update. Thanks for the great support.

Edited May 11, 2022 by storhob21

[WhiteTowerBlackNode]

Hi,

 

I am using the Krusader docker from ich777 and have just a simple question.

While using the Synchronise Folders feature to backup one Unraid share to a remote share (same network), the copying process sometimes seems to halt like this: https://imgur.com/a/BphqlDY (GIF of a small screen recording)

 

I suppose that is due smaller files (less than 10 MB or so) and that they have to be written and indexed by the file system?

 

No cache or parity is involved (setup config where the data is also available somewhere else).

 

[Simon]

I'm leaving this here in case it helps others...

 

Restreamer seems to have received a significant update, and choosing "Web UI" will currently give you a error message in JSON format (404, file not found index.html). The workaround is to just add /ui to the URL. Discussions at https://github.com/datarhei/restreamer/issues/326

[jang430]

Hello.  Thanks to OpenVpn-Client plugin, I was able to connect to my home firewall, using openvpn client.  I installed chromium, and put in the parameter "--net=container:OpenVPN-Client",  When I go into VNC.html of Chromium, I can see Google search homepage.  No site working though.

 

The same ovpn file and user name and password is also used on my mobile phone, and surfing works.   Can anyone help point where to investigate?

Edited May 14, 2022 by jang430

[Pete0]

@ich777 some time ago I had this issue

 

Today I am having exact same problem but I think this time I did not mess up any configuration, see picture:

 

 

Or, at least I hope I did notwhing wrong. Last time I fixed it by removing and reinstalling the contianer. The suggestions you made last time did not help.

 

Not sure what is going wrong here. All I know is that I hadn't the container running for a couple of weeks but the contianer was updated multiple times meanwhile.

 

Edit: a fresh installation fixed it again but having to configure everything again sucks.

 

Edited May 15, 2022 by Pete0

[ich777]

57 minutes ago, Pete0 said:

Today I am having exact same problem but I think this time I did not mess up any configuration, see picture:

Did you maybe run a fix permissions on the appdata share itself or something similar?

 

57 minutes ago, Pete0 said:

Not sure what is going wrong here. All I know is that I hadn't the container running for a couple of weeks but the contianer was updated multiple times meanwhile.

Yes, those where mandatory and necessary updates to the base image and I now also push all my images to the GitHub container registry too.

Nothing has been changed so that it won't work anymore...

 

Your appdata share is set to use cache only or prefer IIRC.

[Pete0]

11 hours ago, ich777 said:

Your appdata share is set to use cache only or prefer IIRC.

That is correct.

 

11 hours ago, ich777 said:

Did you maybe run a fix permissions on the appdata share itself or something similar?

No, haven't done that.

 

Since I had the problem last time I am pretty sure not to have messed with the container or it's configruation too much. Only thing that I see that is different from other working containers is that the appdata directory of firefox has permissions

drwxrwx---

while every other directory has

drwxrwxrwx