Frank1940

I looked at your Diagnostics and you have set the 'Use SSL/TLS:" parameter to 'No'. From this setting, this is what the docs have to say:
(https://docs.unraid.net/unraid-os/system-administration/secure-your-server/securing-your-connection/#ways-to-access-your-webgui)

https://docs.unraid.net/unraid-os/system-administration/secure-your-server/securing-your-connection/#https-with-myunraidnet-certificate-and-with-no-fallback-url

OPen up this link and find this.....

Found this in the AI response from Google:


I believe that one of things that Fix Common Problems scans for is out-of-date plugins...

Yes. This is a disadvantage to large-capacity parity and data disks. Any parity operation will take approximately 2 hours per TB.

Not True! See here for a plugin to do exactly that:

https://forums.unraid.net/topic/195826-plugin-custom-smb-shares/

For a one-and-done solution, see this post and the next two:

https://forums.unraid.net/topic/191221-some-musings-on-smb-and-samba-and-unraid-and-windows/#findComment-1561581

I am not a Linux Guru. And mv is one of those dangerous Linux commands since it runs silently and, like many of the "two-letter" commands, it provides no warning when it is going to reek total havoc!

If moving the files is the only option, let me caution you to test the paths you are going to use.

Use the command to first verify every path:

ls -al

Its output will look like this:


Note that I have started from the root of the Linux file system with the full path name. Once you are sure you have the proper path name, use copy-and-paste operations to build the mv command.

It looks to me like the right hand plug is not seated. (SATA power connectors are notorious for working themselves loose when subject to any force on the connector. It looks to me like you need to 'form' those wires between the two connectors to make sure that it can not occur...)

??? — Did you try the login that you use for your Unraid GUI. Login is 'root' and you should know the password. Since you are a beginner, I will point out that logging in at the console (monitor and keyboard) gives you a command line prompt to type commands on– not a GUI.

And where did you get the 'black screen' (Remember you have to describe accurately what you are seeing and what you are looking at when you describe it to us. We are NOT clairvoyant!)

Did you you make a backup of your Unraid boot drive before all of this problem occurred?

Did you have a lot of data on the server and are you willing to lose that?

Have you looked at your router to see what IP address your router has assigned to your server?

Was that data cable loose or disconnected? If so, that is the reason that disk was disabled! Once disable, it can not be simply re-enabled. Unraid does not work that way.

IF you think this is the problem, see here:
https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself

I would first try this procedure and see if you can get that disk back in service. (Oh, before you actually start start the rebuild, double and triple check that all the SATA connectors (data and power) are firmly seated. SATA connectors are prone to 'loosening' whenever they are 'touched'!!!)

Then install one of the new 24TB drives as parity 2 and build parity 2. You will then have dual parity protection as you proceed onto the next step.

Now replace the Parity 1 disk with the new 24TB replacement.

A very quick google found this:

https://www.techradar.com/pro/major-raid-targets-counterfeit-fake-hdds-from-seagate-wd-and-toshiba-in-malaysia-but-is-it-too-little-too-late

Could you be a victim?

Rename the extension on the Plus.key file and try again...

Try Googling Error 0x80070299 and trying those solutions. Do do some research as it appears that this is one of Windows errors codes that are a catch-all for a number of issues. These are not files with DRM (digital rights management) permissions on them?????

In that google result was this one:

https://forums.unraid.net/topic/125003-cause-of-file-transfer-failures-due-to-file-system-limitation/

You might want to try to copy the troublesome files to a flash drive formatted with exFAT. IF that works then copy the files from the flash drive to Unraid...

From the Add Share page:


As you can see, <space> is not a part of this list. I believe this restriction is more of a ZFS system requirement than a Linux requirement. (PS-- you are not the only one you has reported seeing this warning. I believe this is a new 'warning' was added in one of the recent releases.)

From your Diagnostics file:


I would begin with the d---------s files group. Please note that Linux is case sensitive and Windows is not, So if you have two resources with names like Media and media, Windows will only show one of them!

From the Doc's: https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/shares/#disk-share-guidelines

You didn't do this:


Tip #1 is extremely important. Copying/Moving files between a Disk Share and User Share can result in a file being copied onto itself. (That is why disk shares are not exported/shared by default.)

Very quick explanation. I am security conscience so I have all my shares Private.

I have set up a Share User (kodi_vpn_user) and permitted that user to only have access to the Media Share. (My choice)

I have mapped that share as a Drive on my Windows computer (Y:\ in my case) This is what I use for Kodi access since I use a common database (using the mysql Docker on the Unraid server) for all of the Media content so I only have to update and maintain a single KODI database.

I also have pinned the IP address (consider this to be the Unraid server name on Tailscale) to Windows file explorer. See Below:


With this setup, Kodi works identically as a it does on the LAN.

(I have blocked out the tailscale IP address of my Unraid server because it is a public IP address!!!)

BTW, I thought the instructions for setting Tailscale up seemed complicated when I first read them. But once I started to actually do it, it went very smoothly and everything worked the first time.

EDIT: This screenshot was actually taken off a Windows 11 client that has access to my Unraid server only via Tailscale!

I missed the significance of this statement. Let's have a look at the Unraid side of the equation. (Most of the questions that we see about no connection via SMB are because the security restrictions that MS has on Windows clients!) First, look at SETTINGS >>>> SMB and see that SMB is enabled:


Next check to see that you are 'exporting' the share via SMB. See this screen shot before:


To enable a share, click on the Share NAME in the left column an look at the settings. If you set the security to anything but 'Public' (Very bad choice-- IMO), you have to set the access right for every user that you want to have access to the share.

IF this does not fix the problem, attach your diagnostics file in your next post.

Many times, this condition is caused by a process having a one or more files open and not releasing the file. To test for this, have the array running and 'STOP" the array using the button on the MAIN tab. Time how long it takes the array to stop. There is a timer ("Shutdown time-out (seconds):") under 'Disk Settings' on the SETTINGS tab after which the array forced into shutting down. This will always result in an unclean shutdown and parity check on restart.

If the array fails to stop you will have to figure what is holding the file open. (Docker containers are always a good starting point...)

You don't have write permission here:



This is a standard problem with most Linux distributions. They no longer permit write permissions for group and other by default. Unraid requires -rw-rw-rw- permmissions for files and drwxrwxrwx for directories for SMB and NFS file sharing to work properly for all users (which include 'Guest' user!).

See here for Docker containers.
https://forums.unraid.net/topic/188600-share-permissions-changed-to-owner-99/#comment-1540351

Read this post and the next two:

https://forums.unraid.net/topic/191221-some-musings-on-smb-and-samba-and-unraid-and-windows/#findComment-1561581

There have been some online information where an Windows update was changing network type from 'Private' to 'Public'...

Yes--- They will auto revert back to the default configuration. You can find the defaults here:

https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html

That is because the defaults are all defined in the Samba app. When the various Samba configuration files are processed, each one can changes any of the setting. (Each one of the configuration files can call another file to be processed.) The last change becomes the new setting that is used. (There could be two or three changes to a setting but it is the last one made that 'sticks'.)

Start here:

https://forums.unraid.net/topic/191221-some-musings-on-smb-and-samba-and-unraid-and-windows/#findComment-1561581

Read the next two posts after this. Before trying to 'map' a drive, first make sure that you can see it in Windows File Explorer. (IF you can not access it via Windows File Explorer, you can not map it!) It is also important to realize that you can end up with your Windows client being logged onto Unraid using Guest credentials--depending on you making changes to Windows to allow that --and Windows will only allow one login to each server. So anytime you want to try a new SMB configuration, you have to reboot your Windows client. So if you make changes as described in the above link, remember to do the reboot after you finish all of them

You would use \\Tower in File Explorer to get to your server.

in ident.cfg in the /config directory, there is this setting:



Changing it to "no" and rebooting should allow you to access the GUI using the IP address. (Or you could just wait for the Internet to come back up...)

Start here and read the next three posts:

https://forums.unraid.net/topic/191221-some-musings-on-smb-and-samba-and-unraid-and-windows/#findComment-1561581

For the server not showing up in Windows File Explorer, see here:

https://forums.unraid.net/topic/191221-some-musings-on-smb-and-samba-and-unraid-and-windows/#findComment-1561585