dlandon

My bad. ls /etc/samba/unassigned-shares/

Unraid 6.9 uses NFSv3. Unraid 6.10 uses NFSv4. I suspect your remote server is not compatible with NFSv4. Check the remote server and see if there is anything in the log regrading NFS.

Show the output of the command: ls /etc/samba/unassigned.devices

I don't see anything obvious. Where do you see the UD disk being shared? Does FCP report any share issues?

No. Post your diagnostics zip file.

Looks like a certificate issue. Switch to advanced mode and force an update to see if it clears up.

Preclear prepares it for inclusion in the array, but Unraid has to format it to your desired file format.

Is the log getting large? Your issue might be a streaming issue. Probably best to report it to the LMS developers.

Looks good. It won't be mountable until Unraid formats it.

Can you show a screen shot? How large is your music library?

Go to the UD preclear page and download the logs and post the zip file.

Yes, because parity is not valid until it is completed.

Where are you seeing that? I've never seen an issue with memory leaks.

Do you have a backup so you can recover the database?

Only enable it on the shares that need to be cached. It has a bad habit of caching a lot more that you want, like appdata and system shares that are normally on an SSD and is a waste of resources to cache.

Unless you manually change the mount point, UD will use a default mount point it puts together that can change. Once you manually change the mount point, it will stay committed to that mount point and not change again. Due to some changes lately (probably from udev, not UD), the default mount point changed on some devices.

Yes, but you need to manually resume the preclear. When you start the preclear, you will see a choice to resume preclear where it left off.

When the disk is mounted that lets you run the device script - if you've set up a script for the device. Hover your moue over the icon when it is blue and you'll get a tooltip about what it does.

Change one or both of the mount points/names. They must be unique.

The remote server must respond to a ping or UD thinks the server is offline. You'll need to insure the remote server is set to respond to a ping.

I only see two shares being exported with NFS Private. I'm not an expert in NFS, but I see several issues: May 30 00:15:01 NASDiego kernel: FS-Cache: Netfs 'nfs' registered for caching May 30 00:20:02 NASDiego emhttpd: read SMART /dev/sdg May 30 00:23:22 NASDiego kernel: nfs: server 192.168.29.5 not responding, still trying ### [PREVIOUS LINE REPEATED 9 TIMES] ### May 30 00:24:24 NASDiego kernel: nfs: server 192.168.29.5 OK ### [PREVIOUS LINE REPEATED 9 TIMES] ### May 30 00:35:33 NASDiego kernel: traps: lsof[14990] general protection fault ip:14d946a626ae sp:67a7419c4c3996a4 error:0 in libc-2.33.so[14d946a49000+15e000] May 30 00:36:10 NASDiego emhttpd: read SMART /dev/sdd May 30 00:37:44 NASDiego sSMTP[17929]: Unable to connect to smtp.live.com:465 May 30 00:37:44 NASDiego sSMTP[17929]: Cannot open smtp.live.com:465 May 30 00:38:59 NASDiego kernel: traps: lsof[24250] general protection fault ip:14a6f68a06ae sp:c2a16d50cd4ab2c0 error:0 in libc-2.33.so[14a6f6887000+15e000] May 30 00:39:43 NASDiego kernel: traps: lsof[25761] general protection fault ip:150ef49756ae sp:f6c5a1c26c831fcf error:0 in libc-2.33.so[150ef495c000+15e000] May 30 00:40:21 NASDiego kernel: traps: lsof[27336] general protection fault ip:148790ce86ae sp:b5b3372700e49f2d error:0 in libc-2.33.so[148790ccf000+15e000] May 30 00:40:53 NASDiego kernel: traps: lsof[28685] general protection fault ip:15012a9686ae sp:69d11097c51e1bdf error:0 in libc-2.33.so[15012a94f000+15e000] May 30 00:44:50 NASDiego kernel: traps: lsof[29821] general protection fault ip:14dc918976ae sp:c248730f6b03783b error:0 in libc-2.33.so[14dc9187e000+15e000] May 30 00:45:41 NASDiego kernel: traps: lsof[6048] general protection fault ip:15089db146ae sp:8aabd1c1908fa41f error:0 in libc-2.33.so[15089dafb000+15e000] May 30 00:46:02 NASDiego kernel: traps: lsof[7393] general protection fault ip:1511b4ee76ae sp:3a5a68310d99e4af error:0 in libc-2.33.so[1511b4ece000+15e000] May 30 00:46:59 NASDiego kernel: traps: lsof[8104] general protection fault ip:14d97248a6ae sp:b32be53191ae1a77 error:0 in libc-2.33.so[14d972471000+15e000] May 30 00:51:41 NASDiego kernel: traps: lsof[10465] general protection fault ip:14b6710596ae sp:b16b38e7d4ea06dd error:0 in libc-2.33.so[14b671040000+15e000] Your server at 192.168.29.5 is not responding right away and then goes on-line. Shortly after that you are getting GPFs in libc-2.33.so. Not sure if they are NFS related, but should be looked into. I would remove these lines from your go file as they are no longer needed and the i915 driver has been an issue in the past. modprobe i915 chmod -R 777 /dev/dri Unraid handles this in the latest version.

This is really a discussion for the UD forum, not recycle bin. In UD Settings, you control access to UD devices.

No. What would you change it to? I don't think that is the issue. The IDs are unique, the issue is that the controller is confused on what is installed and being reported to Linux.

It mounts either /mnt/user/ or /mnt/user0/ (selectable) and shares that mount and applies the recycle bin parameters to the rootshare. All the 'shares' work the same as they do separately. The warniing applies to the UD rootshare and is the same if you use the smb-extra.conf configuration. It's the way files are allocated to shares.

It doesn't chain CIFS mounts.