dlandon

I'm not having any trouble with scripts. Is your disk or remote share mounted? The script buttons act differently if the device is mounted. If the script is running, you are even more limited in what you can do. The only button that applies changes is 'Apply'. There's an off chance you are running into a php warning or error. Check the Tools->PHP Settings and see if anythjing is logged.

Currently Unraid's value is 'smbd max xattr size = 65536'. You can try setting this value higher in the smb-extras, but I don't think this is your problem. smbd max xattr size = <new value> I think @Frank1940 may have the answer - see above.

How about you change your strategy and mount and unmount the shares as needed for your backup. You could also add some code to check that the backup server is online by pinging it before auto mounting and either waiting for it to come on line or fail the backup. In pseudo code: Ping remote server and see if it is on line. If not, wait for it to come on line, or fail the backup script. rc.unassigned mount <backup remote share>. Perform the backup... rc.unassigned umount <backup remote share>. I wouldn't have dockers running depending on the remote mount to be available if it is turned off. Coordinate the use of the mount points with when the backup server is on line.

Sounds like you might be getting stale file handles. Post diagnostics.

Look in /flash/preclear_reports/.

A few things to try: You are using tailscale. Check your setup and be sure the 'SARAH' server is seen. Try pinging it from the server that is not showing it as mountable. Ping both the name and IP address. Try using the IP address of 'SARAH' in UD instead of the name. The issue may be name lookup.

Post diagnostics from the server that is failing.

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.