dlandon

I've submitted several PRs today. One adds support for Recycle Bin Next capability to Custom SMB Shares. Once Custom SMB Shares is released with the Recycle Bin Next PR, I'll do some additional testing and then release a new version of Recycle Bin Next. The Recycle Bin Next is available from GitHub: https://github.com/dlandon/recycle.bin-next

The issue has already been fixed in Unassigned Devices Next, which is an independent continuation of the original Unassigned Devices project. If you'd like to use the fix now, install both Unassigned Devices Next and Unassigned Devices Plus Next. Installation instructions and releases are available here: https://github.com/dlandon/unassigned.devices-next The Plus plugin provides the formatting support, including exFAT.

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. This has already been corrected in the current UD Next code.

I submitted a PR to fix this issue.

I've been looking at this plugin because I wanted to see if I could add support for it in the 'Recycle Bin - Next' plugin. It's a clever approach and I think there is an opportunity for the two plugins to work together. 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. Recycle Bin integration. With a working configuration in /etc/samba/smb-custom.conf, the Recycle Bin plugin can automatically update the custom shares with the appropriate Samba recycle directives before Samba is reloaded. The Custom SMB Shares plugin would simply update its configuration and then invoke the Recycle Bin plugin to apply or remove the recycle settings as needed. I've already implemented this on my side, so the integration point is ready if you're interested. I can give you the php code to do this. It's just a few lines of code put where you would reload samba on a change in share configurations. I think this would provide seamless Recycle Bin support for Custom SMB Shares while keeping the responsibilities of the two plugins nicely separated.

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.