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.

I mis-spoke about Samba not supporting the %P. It is supported but should not be used in the vfs recycle module. According to ChatGPT: "%P is valid in Samba generally, but it is not handled safely by the vfs_recycle module. When used in recycle:repository, it can generate invalid paths and lead to smbd instability. There are recycle bin configuration options that correctly handle directory structure without relying on %P, and those should be used instead." The current implementation of the recycle bin plugin does not set those recycle bin options. The %P should not have been used in the recycle bin plugin originally.

You proposed solution will still be a problem. The %P parameter is not supported in later versions of samba and should not be used at all. There are recycle bin parameter settings that will enable the %P action by default. These settings are not set properly in the current release of the recycle bin plugin.

Post diagnostics.

Is the share you are trying this on an exclusive share or a pool device?

Yes, it will stay. I'm working on an update.

No, and probably not. I'm continuing development in my GitHub and it has been renamed File Activity Next to differenciate it from the File Activity V2 plugin forked from my repository to minimize confusion.

A UD disk password is encrypted and stored on the flash drive - never in plain ascii. Don't share the flash drive (using SMB of NFS) if you'e concerned about file access security. If someone physically obtains your flash disk, you'd have bigger problems. A UD disk password is used momentarily (stored in a tmpfs file) to unlock a disk and then immediately shredded after the disk is mounted. The mount command uses the password from the tmps memory file so it is not exposed in the log in any way. UD asks Unraid through an api command to unlock an encrypted disk when the array password is used. UD has no visibility into the array password and has no ability to access it. Rest assured, security has been considered in all Unraid and UD do to handle encrypted disks and passwords. The encrypted lock was how Unraid used to show an encrypted disk. I don't currently have any encrypted array or pool disks, so I don't know how the UI is showing encrypted disks these days. Post a screen shot of how Unraid is currently showing encrypted disks. I'd be interested in seeing how it is currenly being done. Edit: This is a log snippet of an encrypted UD mount using the Unraid api to get the password: Dec 22 15:37:02 BackupServer unassigned.devices: Mounting partition 'sdf1' at mountpoint '/mnt/disks/Testing--dataset'... Dec 22 15:37:02 BackupServer emhttpd: shcmd (422611): /usr/sbin/cryptsetup luksOpen '/dev/sdf1' 'Testing--dataset' --key-file=/root/keyfile <= Unraid api call opened the luks device Dec 22 15:37:14 BackupServer unassigned.devices: Mount cmd: /sbin/mount -t 'ntfs' -o rw,relatime,nodev,nosuid,nls=utf8,umask=000 '/dev/mapper/Testing--dataset' '/mnt/disks/Testing--dataset' Dec 22 15:37:14 BackupServer ntfs-3g[3702069]: Version 2022.10.3 integrated FUSE 27 Dec 22 15:37:14 BackupServer ntfs-3g[3702069]: Mounted /dev/mapper/Testing--dataset (Read-Write, label "Testing--dataset", NTFS 3.1) Dec 22 15:37:14 BackupServer ntfs-3g[3702069]: Cmdline options: rw,relatime,nodev,nosuid,nls=utf8,umask=000 Dec 22 15:37:14 BackupServer ntfs-3g[3702069]: Mount options: nodev,nosuid,nls=utf8,allow_other,nonempty,relatime,rw,default_permissions,fsname=/dev/mapper/Testing--dataset,blkdev,blksize=4096 <= mounted device is mapper, an encrypted disk

Nothing is wrong. That's how UD shows an excrypted disk. The file system shows 'luks' when the disk is not mounted, and the actual file system when it is mounted. The lock next to the orb will show when it is an encrypted disk. Closed when the disk is not mounted - locked, and open when the disk is mounted - unlocked. UD has never shown 'xfs-encrypted' on the file system. That is the selection for an xfs encrypted partition when formatting the disk. The disk is encrypted. As for the file manager, it is probably not aware of the encrypted status of a UD disk.

There is, but it is not addressed by this forked plugin. This forked plugin adds the fruit config that is already managed by Unraid - when not needed and potentially twice: [isos] browseable = No comment = ISO images path = /mnt/user/isos valid users = ********* veto files = /.Recycle.Bin vfs objects = catia fruit streams_xattr catia fruit streams_xattr recycle <= fruit potentially added twice write list = ********* recycle:exclude_dir = ".Recycle.Bin" recycle:exclude = *.tmp recycle:versions = Yes recycle:minsize = 1 recycle:touch_mtime = No recycle:touch = Yes recycle:keeptree = Yes recycle:directory_mode = 0777 recycle:repository = .Recycle.Bin fruit:encoding = native This plugin adds the "/etc/samba/smb-fruit.conf" extra settings to the share configuration regardless of the "Enhanced macOS interoperability:" setting. If it is set to "Yes", this plugin adds the extra settings a second time resulting in duplicate vfs_objects. This is an inappropriate samba configuration and could result in redundant operations and issues. There don't seem to be any other changes made by this plugin to the share configuration, so it's unclear as to what's been "fixed". If having those vfs_objects added appears to fix the samba fault, it is a fluke because that is not the solution. The issue is in how samba handles the repository. The older versions of samba were a bit more tolerant of inappropriate confiuguration settings. The newer versions of samba are stricter about the configuration settings. I discourage the use of this forked plugin as it does nothing to address the issue amd may in fact cause problems.

The malloc assertion botched message is either there was not enough memory to fulfill the request or there is a bug in preclear. Unfortunately, the current preclear script uses a buffer file in the tmpfs ram file system to read and write disk data. Most of the time this shows up as not enough memory that preclear detects and it stops running when preclear sees there is not enough memory. The size of the buffer depends on the disk size and with a bigger disk that can be extremely large. The preclear script needs to be rewritten to do reads and writes without using a memory buffer. I removed the read after write check some time ago that verified that zeroes were actually written to the disk during the write cycle as it was time consuming (the preclear time was about 2X a write cycle alone). The cycle was write zeroes and then read the disk and verify zeroes were written. The read has to insure the actual disk was read, and not the disk buffer. This takes time - at least one revolution of the platter, maybe more for the read after write. I did not get back to to remove the buffer file use as it is a major rewrite. With newer model disks, the cycle should be: Optionally do a pre-read, but don't verify zeroes were actually written. Write zeroes to all sectors of disk without any errors appearing. Don't use a memory buffer. Check SMART report for disk problems while writing to detect a failing disk before a complete write cycle is finished saving a lot of time. Write a preclear signature if disk does not have issues. Optionally do a post-read, but don't verify zeroes were actually written. Modern disks will report issues with reads and writes and show in the SMART report things like pending and uncorrectable sectors that indicates problems. The disk that is hanging is probably a bug in preclear.