dlandon

Turning off the macOS interoperability removes the vfs_fruit on all shares.

I'll have a look.

The lightning bolt is active only when the disk is mounted. Correct. If the disk is btrfs you can only scrub it when it is mounted. All other file systems are checked when they are unmounted. That siunds like a device script issue. You need to stop putting data on the disk and run the scrub. Then run the script and troubleshoot.

Unmount the disk, and then click on the check mark next to the mount point on the UD web page. You should never do that.

Run a file system check also.

Is your disk full? Those should not be happening.

I saw those, but I'm not sure that has anything to do with the script execution. That used to happen when you rebooted and left some browser sessions running. We made a change to prevent that, but you may have an unusual case.

I didn't see the error in the log. The best way to check your script is to mount the drive, then click on the lighting bolt icon and a window will open and your script will be executed. You can then see if there are any errors and fix them. I've done some work on the scripts lately and we may have a new bug to squash.

I'm not a mac person, but you should look at the UD settings. There is one called enhanced macOS interoperability. Press the F1 key and read the help text by that setting at it may be that you need to use that setting. If you don't get anywhere, maybe a mac person can respond as I'm not a mac person.

Correct.

I am not familier with Finder. If you click on the 'Local Backup' text in UD, it will take you to the disk contents and you can browse the folders.

The is the contents of the disk. The 'lost+found' folder is probably lost files restored after a disk check.

New release of UD: Add a link on the UD Settings page to directly go to CA and install UD+. Many issues with logging including erasing logs on every device script call and wrong log file names at times. Some UI cleanups. FIx remote share mounting by insuring the remote server online status is up to date. FIx devices actually installed in UD showing up as Historical devices.

You are very welcome. You're fairly new here, but I think you'll find the support you get on the forum is exceptional. If you ever feel you are not getting what you need, feel free to tag @Squid or myself and we'll be sure to get the right person on the job.

There have been some samba changes in 6.10. One of the latest changes is the addition of samba security. Sorry I can't be more specifc. There is so much going by me in development I can't keep track of it all. If you have the stomach for it, you could run the latest 6.10rc2 or wait for 6.10 final and take a look at it then. For the moment, a wait and see approach might be best,

Glad to hear you got things working. Samba is a rather cantankerous beast and has been known to cause this sort of behavour. What version of Unraid are you using?

If you use NFSv4, you won't see the stale file handles. You will have to use Unraid 6.10rc2 though for NFSv4 support.

I think you are running into the stale file handle issue with CIFS mounts. What I think is happening is you are referring to a file on the cache and when it is moved the file handle has changed and you can then no longer access it. When UD (Unassigned Devices Plugin) mounts a CIFS share, it uses the 'noserverino' parameter that prevents the stale file handle. Example UD mount command: /sbin/mount -t 'cifs' -o rw,noserverino,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=99,gid=100,credentials='/tmp/unassigned.devices/credentials_Public' '//MEDIASERVER/Public' '/mnt/remotes/MEDIASERVER_Public' Basically what the 'noserverino' does is use a local 'ino' and the not the server 'ino' which can change if the file is moved. Take a look at all the parameters used here and see if any others would apply to your situation. Give that a try. Let me know how it goes and we can work on it somemore.

I was able to reproduce this situation and I'm working on a fix.

Security settings are planned for 6.10.

You can't use a devX name. UD rejects it. Just enter something like 'DIsk_1'.

The Historical devices lists any device that has been seen by UD. If you unassign a disk from the array, UD will see it and create a Historical entry. If you assign a disk back to the array, just delete the Historical device entry by clicking on the red 'X'. In the future, you can get faster support by posting in the UD support thread.

The devs.ini does indicate 4 unassigned disks. The dev2 in the Historical devices is what was assigned that disk the last time UD recognized it and has nothing to do with the current dev2 assignment. It shows the dev2 when a Disk Name hasn't been assigned. Try doing this: Click on the device edit icon (three gears) on the Historical device and set the 'Disk Name:' to something other than the default value showing. Be sure to click 'Save' to save the new disk name. Then click on the double arrows on the upper right of the UD page to refresh the configuration and see if that device shows up in UD. If not, please PM me the output of the following command: cat /var/state/unassigned.devices/unassigned.devices.ini It's a messy file to post in the forum.

I just released an update to the recycle bin. The recycle bin works with UD if it is installed to add the recycle bin to disk devices. I made a change to UD that highlighted a problem in the recycle bin that may have caused the recycle bin parameters to not be set in the Unraid shares. What this means is that when the recycle bin parameters are not added to the shares, it will not put files in the recycle bin. For those of you that have been having issues with the recycle bin not working, please update to this latest release and see if it works now. If you still have issues, post here and let's see if we can't get it sorted out.

Show me the output of this command: cat /usr/local/emhttp/state/devs.ini