pbear

Deemix doesn't work anymore since a long time. I had to switch to DeemixFix (app). You could unlist it.

Yes thanks, this addition to the go could be a solution. Afterwards, as I said, I don't reboot the server often, I now know the problem and am always forcibly present when I update or upgrade the hardware, so it's not really blocking. But if there's a bug with the interfaces like you suggest, or something else, it would be cool if someone looked into it and solved the problem. It looks like ipv6 isn't very popular :D (I'm thinking of Unifi, which still doesn't support ipv6 in vpn connections in 2025, grrrr).

Same problem with v7.1.4: # ss -tulpn | grep ssh tcp LISTEN 0 128 10.0.2.2:22 0.0.0.0:* users:(("sshd",pid=1979,fd=6)) # /etc/rc.d/rc.sshd restart rc.sshd: SSH server daemon... Started. # ss -tulpn | grep ssh tcp LISTEN 0 128 10.0.2.2:22 0.0.0.0:* users:(("sshd",pid=3493488,fd=7)) tcp LISTEN 0 128 [2a01:xxxx:yyyy::2]:22 [::]:* users:(("sshd",pid=3493488,fd=6)) Why on earth doesn't the ssh server listen on ipv6 as soon as the server starts up?! @ljm42 As you helped me last time, and had tracked down an issue with fixed ipv6s, I'd like to ask you if you might have an idea about my rather similar problem. Thank you in advance.

I had the same problem after upgrading to v7.1.2 : The ssh server does not listen on ipv6 by default. I have to do a manual restart of the ssh deamon to solve the problem. Fortunately, I don't reboot the server every week, but it's still not normal. Am I the only one with this problem?

Hello, Since I upgraded, my server no longer listens on its ipv6 address. I'd already had this problem with a previous update: This time it was a bug and was corrected with the next minor version. But here the symptoms aren't exactly the same, so I don't know. The network interface has its own ipv6 and it's up and running: # ip addr show br0 6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether c8:7f:54:a9:c2:1b brd ff:ff:ff:ff:ff:ff inet 10.0.2.2/24 metric 1 scope global br0 valid_lft forever preferred_lft forever inet6 2a01:xxxx:yyyy::2/64 metric 1 scope global valid_lft forever preferred_lft forever # ping google.fr PING google.fr (2a00:1450:4007:810::2003) 56 data bytes 64 bytes from par21s03-in-x03.1e100.net (2a00:1450:4007:810::2003): icmp_seq=1 ttl=112 time=13.0 ms 64 bytes from par21s03-in-x03.1e100.net (2a00:1450:4007:810::2003): icmp_seq=2 ttl=112 time=7.46 ms This time, unlike the previous case, my ssh config file is populated with my ipv6 address: # grep Listen /etc/ssh/sshd_config ListenAddress 10.0.2.2 # br0 ListenAddress inet6 2a01:xxxx:yyyy::2/64 # br0 But the ssh server doesn't listen on it: # ss -tulpn -4 | grep ssh tcp LISTEN 0 128 10.0.2.2:22 0.0.0.0:* users:(("sshd",pid=1943,fd=6)) # ss -tulpn -6 | grep ssh # When I restart the ssh service I get no error. EDIT: I just noticed that after I did the /etc/rc.d/rc.sshd restart, as I said I got no error and .. it now is listening on the ipv6: # ss -tulpn -6 | grep ssh tcp LISTEN 0 128 [2a01:xxxx:yyyy::2]:22 [::]:* users:(("sshd",pid=134056,fd=6))So I don't know what happened, or if I'll have the problem on the next reboot (in which case I now know how to solve it) but it's solved. Moderators: you can delete my thread if you think it's no longer of interest. Thank you.

Hello, When I installed I get these errors: plugin: skipping: python3-3.13.0-x86_64-1dwl_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 plugin: skipping: python-pip-24.2-x86_64-2dwl_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 plugin: skipping: python-setuptools-75.1.0-x86_64-2dwl_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 plugin: skipping: python3-3.12.7-x86_64-1dwl_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 plugin: skipping: python-pip-24.2-x86_64-1dwl_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 plugin: skipping: python-setuptools-75.1.0-x86_64-1dwl_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 plugin: skipping: python3-3.11.10-x86_64-1dw_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 plugin: skipping: python-pip-24.2-x86_64-1dw_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 plugin: skipping: python-setuptools-75.1.0-x86_64-1dw_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 How to fix it ?

Hello, Right, it's https://github.com/KatyPurry/unraid who created the template I believe. Although he seems to be still active (on GitHub at least), he didn't notice that you suddenly deleted https://raw.githubusercontent.com/alexta69/metube/master/favicon/android-chrome-384x384.png Or he does not care. Maybe it would be easier to ask you to put it back ?

Indeed it works with bridge. Thanks. Is this template unique? I mean usually I can change the port with a dedicated ip. How to know when the web env variable is only for bridge ?

Hello, I just installed Privatebin I've setup a WebUI port but it still listen to the default 8080 only 🤷‍♂️ I tried with dedicated ip or host network config.

Hello, I just installed Yacy but it does not start: could not copy yacy.logging: /opt/yacy_search_server/DATA/LOG/yacy.logging (No such file or directory) STARTUP: Trying to load logging configuration from file /opt/yacy_search_server/DATA/LOG/yacy.logging could not find logging properties in homePath=/opt/yacy_search_server Any idea ? EDIT: I had to do chmod -R 777 /mnt/user/appdata/yacy It fixed the problem.

@JorgeB Hello, I discovered and activated this option just yesterday. I had the same questions than @casperse and this thread has answered it. > exclusive shares makes /mnt/user/share the same as /mnt/disk/share, with the performance advantages that come from doing that So if there is no counterpart, why isn't it 'by default' ? Why is there still a fuse layout ? Thks

Hello, Thks for the script. Just a remark: In your doc you should modify this: by the raw link that you've mentioned above ^^

Hello, About the docker Dozzle, Even when we change the env variable WebUI for another value, the daemon still listens to 8080. This env. variable is by default in the template.

Problem solved with the new v6.12.6 indeed 👍 Thanks for your work.

I confirm this v6.12.6 solved the ipv6 problem I had since v6.12.4 , the sshd now listen well on every ip \o/ Thank you for this release, have a nice day everybody.