dlandon

If your recycle bin is large and your server very busy, it can take a while for the recycle bin to load. It will eventually time out and you may see a ? Where some of the sizes should show. Based on the log snippet, it looks like you may have other issues. Post diagnostics.

Unassigned disks are disks not assigned to the array as parity, data, or cache. Those disks are assigned to the array. You’ll not see them as unassigned disks.

You are using disk shares. There was a typo in the script that removes the recycle bin contents. I just released a fix.

Tools->Diagnostics.

Any SMB or NFS share will be shared locally as an Unraid share (show in \\Tower) based on the settings in the Settings->Unassigned Devices. If you don't set up security there, then all shares will be shared public and any Windows computer can browse the shares. Based on what you are telling me, you probably want to share them hidden. That way they can't be browsed.

That's not the way it is supposed to work. Post diagnostics.

Show me where you see them. I don’t see them in the diagnostics.

Your disks are not recognized by Linux.

Your drives should show here:

Remove the UD plugin and then navigate to the Unassigned Devices tab and show me a screen shot. It looks like the disk drive designations are not being recognized by UD.

Post diagnostics. Tools->Diagnostics

UD has to ping so it can show the status of the remote server. The share might be mountable, but UD doesn't know that without the server responding to a ping.

Your server appears off-line to UD. The server has to respond to a ping or UD thinks it is off-line. Feb 7 09:57:30 Tower unassigned.devices: Error: Remote SMB/NFS server '192.168.0.10' is offline and share '//192.168.0.10/TV_Shows' cannot be mounted. Be sure your remote server is configured to respond to a ping. This is what the SMB indicator shows when the remote server is on-line.

Show another screenshot of UD so I can see the mount point. Also post your diagnostics.

Update to the latest UD plugin version 2019.02.05a. There was a bug in the previous version.

Update the UD plugin to version 2019.02.05a. There was a bug causing this problem in the previous version.

Fix is on the way. I'll update the UD plugin soon. I was attempting to block special characters from the mount point when entered manually, and stripped off the slashes when the share was initially setup.

This is a UD plugin issue, not an Unraid bug. Please close this bug report and post this in the UD support forum.

There is a situation with the vfs_recycle module of samba that can cause a problem with the recycle bin plugin. If you create a share with an apostrophe in it, the vfs_recycle will remove the apostrophe and replace it with an underscore and create the .Recycle.Bin on that share. For example you define a share "Dan's Stuff" and delete a file from that share. The vfs_recycle module will create a folder "/mnt/user/Dan_s Stuff/" and put the .Recycle.Bin there. Unraid sees the folder and creates a new share "Dan_s Stuff". You will then see both shares when you browse. For the time being I recommend either: - Don't create a share with an apostrophe. - Exclude the share from the Recycle Bin. There isn't anything I can do to get around this issue. We'll just have to wait for the vfs_recycle module to be fixed.

Based on what you are saying, I think the scenario I described is what happened to you. The diagnostics probably won't have any value. I'd also recommend you make backups of your data so you can recover from a situation like this.

That's not really a good answer because a phantom share is created by Unraid without the user's knowledge and both show in a browser. Very confusing. I'd say the thing to do right now is to not enable the recycle bin for that share.

Until recently I wasn’t even aware you could do that.

I have developed a theory for how this happened. Let me describe how the old and new methods of emptying the share work. There are two pieces used to remove the contents of the .Recycle.Bin folder. The UI passes the share recycle bin reference to a script that does the actual removal. Old way: When the Share empty button was pressed the UI passed the share path to the script that removed the .Recycle.Bin contents. The script appended the '.Recycle.Bin' to the passed in path to the share. In your case the UI would pass in /mnt/user/SHARENAME and the script would append the .Recycle.Bin folder to the share path to make /mnt/user/SHARENAME/.Recycle.Bin which is the proper folder to the recycle bin contents. New way: A symlink is created for each share with recycle bin contents at /mnt/RecycleBin. This was originally created to make the Unraid file browser work. For several reasons, I decided that it would be better for this to be used for the UI for browsing and share empty functions. So now the UI passes in the symlink to the share recycle bin directly to the script and the script just removes the recycle bin contents from the share symlink path directly because it already references the share .Recycle.Bin. The passed share recycle bin path is then /mnt/RecycleBin/SHARENAME which is the correct path to the .Recycle.Bin folder. Your sequence of operations as best as I can tell is: - Browse to the recycle bin UI to look at SHARENAME recycle bin contents and remove a deleted file. - Decided to check for an update first and see if there is an update. - Update the recycle bin plugin. - Go back to the recycle bin UI and empty the share recycle bin. The old UI is cached? I am not an expert at how browsers cache web pages, but I think that the recycle bin UI was not refreshed to the new plugin version. The script would have been updated, but the UI web page may not have been. So you have the old method of the UI and the new method of the script. The old method UI would then pass /mnt/user/SHARENAME to the script but the .Recycle.Bin would not be appended as in the old way of doing things and the /mnt/user/SHARENAME contents would be removed because the script expected it was a symlink to the /mnt/user/SHARENAME/.Recycle.Bin folder. I know this is a stretch, but I could see how it could happen. What I've done in the latest version is to block removal of the share recycle bin contents if the path is not /mnt/RecycleBin/SHARENAME passed in to the script and log an error.

I'm not sure it warrants a lot of your time.

Well isn't that just special! So anyone with an apostrophe in the share name will have Recycle Bin issues. I can't work around that.