dlandon

You have to enter the correct credentials in order to list the shares. As a test, when you get to the part where yoiu enter a share, enter a share manually. Then mount the share and let's see if an error shows.

Your best bet is to upgrade to 6.11. The other option is to copy the /boot/config/plugins/ folder from a backup and reboot.

1. Probably not because I don'rt think there is enough room to fit it in. 2. The appdata, syslog, and system shares are excluded from file activity and won't show any activity.

This might be affected by the excluded files in the recycle bin. As I mentioned already, this is a very bizare get around and I don't expect it to work in all cases. It's going to end up being up to the samba development team to find the final solution.

I've done some testing and found out Samba is crashing: [2024/03/14 09:07:19.329402, 0] ../../source3/smbd/fd_handle.c:39(fd_handle_destructor) PANIC: assert failed at ../../source3/smbd/fd_handle.c(39): (fh->fd == -1) || (fh->fd == AT_FDCWD) [2024/03/14 09:07:19.329435, 0] ../../lib/util/fault.c:178(smb_panic_log) =============================================================== [2024/03/14 09:07:19.329442, 0] ../../lib/util/fault.c:179(smb_panic_log) INTERNAL ERROR: assert failed: (fh->fd == -1) || (fh->fd == AT_FDCWD) in smbd (smbd[192.168.1.) (client [192.168.1.188]) pid 22564 (4.19.5) [2024/03/14 09:07:19.329447, 0] ../../lib/util/fault.c:186(smb_panic_log) If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting [2024/03/14 09:07:19.329451, 0] ../../lib/util/fault.c:191(smb_panic_log) =============================================================== [2024/03/14 09:07:19.329464, 0] ../../lib/util/fault.c:192(smb_panic_log) PANIC (pid 22564): assert failed: (fh->fd == -1) || (fh->fd == AT_FDCWD) in 4.19.5 [2024/03/14 09:07:19.329708, 0] ../../lib/util/fault.c:303(log_stack_trace) This is with samba 4.19. I seem to have found a get around, but I'm baffled right now about why this works. Install the recycle bin plugin and be sure it is running. In my testing it looks like file deletes work. Deleting directories works but an error is displayed and the Android app does not show the directory as being deleted until closed and re-opened. The directory delete also crashes samba. Since the recycle bin plugin is for deleted files through SMB, there is something the recycle bin vfs is doing that prevents the file deletes from failing in this situation. Because samba is crashing it looks to be an issue that the samba team needs to fix. At this time, I don't see any way through samba settings we will be able to fix this on the Unraid side. It could also be an issue with the Android app, but I doubt it. In doing some research, there is a samba bug here that might solve the issue.

Are you using the recycle bin plugin?

What Android app are you using? I'd like to do some testing.

Update UD and see if it is fixed.

The recycle bin is refreshed every 5 minutes and won't show a deleted file right away. The log should show files deleted immediately.

The shares only show in the recycle bin if they have deleted files in the .Recycle.Bin/ folder on that share. Files deleted in network (SMB) shares that are zero length, don't show in the recycle bin. Post diagnostics.

Can you post the screen shot of the php warning, or go to Tools->PHP Settings, and show the warnings,

Turning on NetBIOS in SMB settings enables SMB1. SMB1 is an old protocol and is not very secure. I would not expect LT to invest any time in making changes to an older, unsecure protocol to work better with Unraid. It needs to be fixed on the Android side - like update SMB support to v2 or v3.

UD does not mount optical drives. The best way to use them is to with a VM or Docker Container. Once you start makemkv, the log will show the two devices needed for makemkv to be able to use the drive. You then specify the drive designations of the drive you want to use in the template. Post on the makemkv forum for additional infoirmation.

I think I have a fix. UD was doing a zpool operation when it was not necessary and that will spin up a disk. I'll do some testing and if it works out, the fix will be in the next release of UD.

I was looking at the code and may have found an issue. Standby.

"ZFS file systems have built-in mechanisms such as periodic scrubs, snapshots, and metadata updates that can prevent disks from entering standby mode. These operations are designed to maintain data integrity and can cause disk activity even when the system is idle, keeping the disks from entering low-power states." That being said, UD has to check unassigned disks when it polls for various status and may be triggering a zfs disk operation. It acts differently from a pool disk because UD disks come and go and pool disks are static and only change when the array is started or stopped. If the UD disk is not mounted, you can detach it and that will put it into a standby mode. If it is always mounted, I would suggest moving the disk to a pool disk. I notice some disk read operations when a zfs disk is unmounted, and I may put a little time into understanding what UD is doing that might cause that.

Install UD and detach the drive. It will then show in the Historical devices.

Next time try clicking on the double arrows on the preclear page and see if that doesn't fix preclear.

That's not a weird solution. What that means is that the name resolution is taking a while and using the IP address that doesn't rely on name resolution gets past that.

Your wait timer before mounting remote shares is 30 seconds. Make that several minutes and see if that's enough time for things to get settled and allow the mounts.

It looks to me like the remote shares are auto mounting because 30 seconds after UD says it's waiting 30 seconds, the remote shares start mounting. But two did not mount. Then I see where you loged in and mounted two manually: Yes. There may not be long enough time waiting for the remote server to be available. There is a UD setting that sets how long UD will wait to mount remote shares. Currently you have it set for 30 seconds: Mar 8 07:32:10 Monolith-6 unassigned.devices: Waiting 30 secs before mounting Remote Shares... The setting is 'Remote share mount wait time' in Settings->Unassigned Devices. UD will also attempt to update the online status before trying to mount remote shares, so it should automatically get the current status before mounting.

It looks to two shares from one remote server that won't mount: The server offline means the server port for NFS (port 2049) is not open on that server. UD does not ping anymore to check for a server being online.

Post diagnostics.

Based on all you've been through, I think it might be time to look at hardware issues: Do a memory test. As @JorgeB suggested boot Unraid on an old laptop or another computer and test the file transfer. Replace motherboard and processor?

No. The apfs driver used in UD is read only.