dlandon

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'.

Keep in mind that you need to now set a MAC address on the docker container if you depend on a static MAC address.

Squeezebox Radio here working fine.

None of the containers will auto update LMS. Latest is the same as previous builds - no LMS updates. I need to build new containers for the stable and development to get any new LMS updates. The periodic container refreshes is to update the OS and packages.

I have created docker containers for the 'Stable' and 'Development' versions of LMS so you can run either of those versions as you wish. Refer to the first post on how to install either of those versions. There aren't any changes in the 'Stable' and 'Development' versions that would prevent a downgrade. So you can go back and forth if you wish. The 'Stable' verson has a few updates posted nightly, and the 'Development' version is the 9.2 development which is the 'bleeding edge'. Use at your own risk. The 'Stable' and 'Development' docker containers do not update, so I will have to refresh the docker containers to include any changes since the last container build. If you see something before I do, let me know and I will refresh the appropriate container.

I've released an update to LMS that upgrades the container OS to noble (Ubuntu 24.04) and cleaned up some ownership and permission issues. One of the things upgrading to noble did was increase the Audio::Scan version to 1.10. Someone had asked about this some time ago because Jammy was stuck at 1.05 if I recall correctly. I had most of my music ripped to wma and wma pro files and this was causing me some playback issues. I went through the process of converting all my music files to flac, and no longer have the issues. The down side was an enormous increase of my Music Library size, but that's not really an issue for me as I have a lot of space on my server.

ownCloud is not a front end to your array files.

ownCloud doesn't normally track files added, deleted, or moved on the server side. Files are only tracked when added, deleted, and moved from the ownCloud interface - either by sync'ing or the through the UI. You'll cause database issues by managing files on the server side. Use the ownCloud app 'Files Clipboard' to manage files and folders in the ownCloud UI.

I've released an update to the docker and added an environment variable: You'll find this setting in the Hidden settings. The reason for this setting is to allow browsing to the Settings page without getting a 403 Not Allowed error when using a VPN, Proxy, or Tailscale to access your server. It defaults to on ('1') which keeps the protection enabled. Set it to ('0') if you have issues browsing to the Settings page. Be aware, this setting was to prevent access to the Settings page if it was detected that it was not on the local LAN. Since the advent of VPNs and Proxies, it may not apply now.