dlandon

The Event Server was having issues on the initial Tailscale implementation release connecting to the Event Server port 9000. Today's release fixes the Event Server notifications in ZmNinjaNg.

Tailscale support addedThe ownCloud container now supports Tailscale for secure remote access without requiring public DNS, router port forwarding, a static public IP address, or a publicly managed SSL certificate. I have tested the following through Tailscale: ownCloud browser access ownCloud Android application access File uploads and synchronization Tailscale-managed HTTPS certificates Because ownCloud uses an internally generated self-signed certificate, set the Tailscale Serve Target to: https+insecure://localhost The Tailscale WebUI and client URLs must not include the container’s :8443 port. Including the port connects directly to ownCloud and presents its self-signed certificate instead of the trusted Tailscale certificate. The container’s Tailscale hostname must also be added manually to the trusted_domains array in ownCloud’s config.php. Complete setup, client configuration, certificate, and rollback instructions have been added to the first post in this thread.

Tailscale support addedThe ZoneMinder container now supports Tailscale for secure remote access without requiring public DNS, router port forwarding, a static public IP address, or a publicly managed SSL certificate. I have tested the following through Tailscale: ZoneMinder browser access ZoneMinder API access zmNinjaNG access Tailscale-managed HTTPS certificates ZoneMinder uses an internally generated self-signed certificate, so the Tailscale Serve Target must be set to: https+insecure://localhost This allows Tailscale Serve to connect to ZoneMinder internally while presenting a trusted Tailscale certificate to clients. Complete setup and testing instructions have been added to the first post in this thread.

The problem I was having with this plugin is I had no way to test the plugin since I don't have a Windows server. As you found out, there was a lot lacking and some bugs. I took it down because I didn't want anyone using it in it's current form with all the issues and bugs I had no way to reasonably resolve. I will make my GitHub Public Archive and add a link to your GitHub with a note the work is carrying on there. Thanks for the recognition of the work I did. Feel free to carry on the effort.

Thanks for the information. The process listing confirms that LMS and the Spotty authentication process are both running as nobody: nobody 668 ... /usr/bin/perl /usr/sbin/squeezeboxserver --u nobody ... nobody 712 ... /spotty-x86_64 ... --authenticate The /config and /config/cache directories are also correctly owned by nobody:users. So the Docker container appears to be setting the ownership and running LMS correctly. I don't see anything at the container level that would explain why Spotty's credentials.json is being created as root:root. I'd suggest continuing this with the Spotty developer since the Spotty authentication process itself is running as nobody.

Give me the output of these commands: docker exec LyrionMusicServer ls -ld /config /config/cache and docker exec LyrionMusicServer ps -eo user,pid,ppid,args

The -13 error is a credentials issue. Check your credentials.

There is way to trick UD and get it to do what you want. I have a UD disk mounted: With file contents: I add remote shares for the UD disk folders I want to share: You can change the name of the share by changing the "Mount Point". Be sure to turn on the share switch. So then you see this in the Windows Shares: When you add the Remote Share, you have to enter the share folder manually because the scan for the shares only shows the top level share. You can add any folder on the UD disk. You can do the same thing to a remote share by adding another remote share that points to the remote share sub folders. Add a main remote share "192.168.0.3_Family Files/" with Mount Point "192.168.0.3_Family Files". Be sure to enable sharing. Add a remote share "192.168.0.3_Family Files/!Home Videos/" with Mount Point "Home VIdeos". Be sure to enable sharing. Add a remote share "192.168.0.3_Family Files/!Pictures/" with Mount Point "Pictures". Be sure to enable sharing. And any others you want. You will then see "Home VIdeos" and "Pictures" in the network shares. You need to add the sub folders manually in the add a remote share dialog.

Your diagnostics show the drive itself is not the problem. The partition table was created successfully, but the format failed because the plugin is trying to execute: /usr/sbin/mkfs.exfat On current Unraid releases, mkfs.exfat is actually located at: /sbin/mkfs.exfat The important line in your log is: Format failed: sh: line 1: /usr/sbin/mkfs.exfat: No such file or directory So the partitioning completed successfully; only the filesystem creation failed because the executable path is incorrect.

I submitted a PR to fix this issue.

I have a few suggestions that might simplify integration: Limit custom share paths to /mnt/user. The /mnt/disks and /mnt/remotes paths are managed by Unassigned Devices (UD). Those mount points can appear and disappear as devices are mounted, unmounted, attached, or detached, so they are not as stable as Unraid user shares. UD already manages SMB sharing for those paths, so I don't think they should be offered as Custom SMB Share locations. Use a working configuration in /etc/samba. Currently the custom share configuration is stored on the flash drive at /boot/config/plugins/custom.smb.shares/smb-custom.conf and included via the "SMB Extras" mechanism. I think it would be cleaner to keep the persistent configuration on the flash drive, but generate a working copy in RAM at /etc/samba/smb-custom.conf and include it directly with: 'include = /etc/samba/smb-custom.conf'. That's consistent with how Samba's runtime configuration is managed elsewhere in Unraid.

Done.

How does it show in UD? Screen shot?

I just changed the default. LMS has been set to Bridge forever.

I'm doing some testing. I have a new Squeezebox Radio that can't see the LMS. Try setting the Network type to 'Host'.