dsmith44

Thank you @chchiyan, not sure what happened there, now fixed.

Yes that does indeed fix the issue, so I got digging. I have DOCKER_OPTS set in /boot/config/docker.cfg as per Removing this and problem is solved, and as I no longer need remote access I'm good, however this will bite others potentially. It's the -H tcp://0.0.0.0:2375 that causes the delay for me, somewhere between 15 and 30s. Thanks

I setup an inotify on /var/run and ran a tail of /var/log/syslog Jun 11 23:06:47 unraid emhttpd: shcmd (362): /etc/rc.d/rc.docker start Jun 11 23:06:47 unraid root: starting dockerd ... /var/run/ CREATE dockerd.pid Jun 11 23:06:47 unraid avahi-daemon[14531]: Server startup complete. Host name is unraid.local. Local service cookie is 39991689. Jun 11 23:06:48 unraid avahi-daemon[14531]: Service "unraid" (/services/ssh.service) successfully established. Jun 11 23:06:48 unraid avahi-daemon[14531]: Service "unraid" (/services/smb.service) successfully established. Jun 11 23:06:48 unraid avahi-daemon[14531]: Service "unraid" (/services/sftp-ssh.service) successfully established. Jun 11 23:07:02 unraid root: Docker not running, can't start containers /var/run/ CREATE docker.sock You can see that the CREATE of docker.sock is after start_containers complains docker isn't running. Looking through rc.docker this puzzles me as wait_daemon is called in start_network so I'm at a bit of a loss

There is some kind of race condition here. If I add a sleep 10 into the rc.docker script before start_containers then when I disable and re-enable docker then it works. It is failing is_docker_running due to lack of /var/run/docker.sock This appears <2s after start_containers complains that docker isn't running from my testing.

1.42.0 = latest

Thanks I am slightly lost on best way forward here. The array thinks the parity is fine, but we know it isn't, it is effectively dead, meaning the current array is toast given that it thinks the other drive isn't ok. I think what I need to do is start again, but absolutely do not want to loose my mirrored cache pool. To do that I plan to do the following New Config Preserve all slots Remove current failed parity from new config. Config will be 1+1 SSD cache pool, 4 array drives without a parity (disk0/sdj) , disk2/sde questionable. Start array. Move data off potentially failed disk2 to disk1/3/4. Shutdown array. Add 2x6tb new drives, probably after a zero to make sure they are ok. Add one as new parity. Add 2nd as new drive. Remove disk2. Start array and wait for parity to build. Is that my best way forward? Thanks

unraid-diagnostics-20230531-1022.zip

1.40.1 = latest 1.42.0 is available

The situation is that a drive showed up as failed, and was being emulated. Shutting down the array and running an extended SMART test on the drive it actually seems fine, however my partiy drive that unraid says is fine just isn't. When restarting the array for a rebuild the parity drives is all read errors after a few minutes, and won't even finish a short SMART test, never mind an extended one. 6 drives ( 5 + 1 ) My understanding is that I'm better off just starting a new array without the parity drive, the original failed drive will still have it's data unless formatted, and then install a new parity. Before I do anything, I wanted to check if that is correct? Thanks

1.4.0 has been uploaded, if you want it. I won't tag latest just late as previously discussed

latest = 1.38.4 = 1.38

1.38.2 == 1.38 == latest.

1.38 == 1.38.1 is pushed. Latest will move in a week or two

It looks like tailscale cannot connect to the internet at all, which is why it is failing. If you open the console, right click on tailscale container, can you ping anything?

As this is a docker container, and not a plugin, there is no way for it to interact with the underlying unraid install. Sorry.

Latest = 1.36.1 = 1.36 Anyone that pulled 1.36.0 I would suggest updating as there are issues with this .0 release fixed in .1

1.36.0 is the latest available if you read the previous posts. 1.36.1 came out yesterday. Latest tag will be moved to 1.36.1 in the next few days.

You can change the version of any docker container you pull in the settings. Where it says deasmi/unraid-tailscale or deasmi/unraid-tailscale:latest change it to deasmi/unraid-tailscale:<VERSION> Note that you will not get updates if you do that without manually changing it again. Unless there is something in 1.36 you desperately need, and looking at the release notes I'm not sure what that could be, I would leave it alone and you'll get it after a few weeks anyway.

For those that would like it you can pull 1.36.(0), I will tag latest in a few weeks if there isn't a 1.36.1

Last follow up on this, I connected to the console of my tailscale docker container and tried to ping another container that I have with a static ip address on my lan. I cannot ping this, and so there is no hope of tailscale being able to route traffic to it. I think the reason for this is:- arp packets will be sent onto the ethernet from tailscale to get the mac address of the host with the ip addres, these arp packets will hit your ethernet switch, where it will broadcast them to all ports, except will not send them back the way they came and so the docker container never sees them, and doesn't respond. So the tailscale docker never sees an arp response, so can't send the packet to the right mac address, so cannot connect to it. As I said, this isn't supported, and in fact cannot ever work now I've thought about it.

If you want to use routes, and get onto you network, I can only advise not using unraid as the place to run tailscale, put it on your firewall or even a raspberry pi. It's not the inteded use. If someone wanted to add tailscale network vpn to unraid, should be in a plugin, not a container. Running a vpn endpoint, inside a docker container, on a NAS, is asking for trouble/complexity. I would connect to the console of the tailscale docker, and see if you can ping the other thing, if you can't this isn't a tailscale issue, it's a docker networking issue. This may also be a place to start to get it running outside of docker. https://gist.github.com/shayne/25e194e068751e281937ef68edefb99b

Ok, anything to do with advertise routes is specifically unsupported. It's custom networking, and at that point you need the tailscale forums, not unraid. I've added some more info to the front page to make this clear. However on the plex front I'm not even sure what you are saying exactly. Are you saying with a vanilla tailscale setup, no routes, no extra flags, when tailscale is running remote users can't use plex ? They wouldn't be going over tailscale in this instance anyway. Mine works completly fine in this situation, so if your install isn't we can try and debug that, but not with routes, sorry.

You are into advanced and unsupported, but if you add —advertise-routes= to the command line you will be acting as a router, then **probably**.

Latest = 1.34.1 = 1.34