Frank1940

Please understand this is not the first time this problem has come up. Persons who have disks formatted with reiserfs (File system drivers for it have already been dropped from current Linux kernel-- It will affected Unraid users when LimeTech switches to version 6.13 of the Linux kernel!) and a few folks with an old version of xfs which will have to updated to the latest xfs version. So if there was a way to do it without copying the data off first, it would be known. I am sorry but that it just one of those nasty facts of life.

Only way is to copy data off before formatting. Sorry...

The longer the interval between parity checks, the greater the need for the system administrator to actually spend time monitoring what is going on. With a longer interval and a neglectful admin, the higher the probability is that the array will eventually have more failures than the parity can recover from. (If the system is not monitored actively, a disk failure can go undetected for months as parity can cover for it With the speed of modern disks and hardware, parity-build data recovery is virtually transparent to the average user!)

You can do as you like. Personally, I would just leave it there as it deleting it involves a write operation that shortens the life of the drive... 😁

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

Did you look in the /config folder to see if there was a file with a .key extension? IF it is not there, do you have a backup of the old flash drive that you made previously? IF you do, look for the .key there and copy it to the new flash drive. When all else fails, contact support and give them the details of your license purchase. They usually resolve these problems rather quickly.

Let's try this. Go to Shares and click on your 'data' share name under "User Shares". Then set 'Minimum free space:' according to the instructions below in this screenshot. (Your present setting looks like the default setting which is usually way too large.)

Let me point as things stand now" jr" will be able to write to the 'Pictures' share and "nobody" to the 'icloud-drive-sync' share. Any other Share Access user will be denied write permission since they will be accessing the share as a member of the 'users' group. This is regardless of the permissions you have set up under the GUI's SMB Share settings.

The second "user" in this path is the name of a Share. Is this a typo or what? Let's redo your using the command line rather then Krusader. Open up the GUI Terminal and type ls -al /mnt You should get something like this: (The entries in green are there because I have the unassigned devices plugin installed.) Now let's look at your user listing. Type this command: ls -al /mnt/user Now, get a screen capture of the output. (You can cut off the most of the Share names (for privacy) but leave the first few letters so we can tag those in any response.) Before you ask. user0 is will give a listing of shares and files that are not on a cache drive or in a cache pool. It is considered to deprecated but it has not been removed as some folks have said that they still use it...

You have not given us much to work on here. At least, provide us with the first and last letter of the Share you are trying to write to. Next thing: There are restrictions on Share names. This screenshot is from the Add Share page on the GUI: Another thing, you have not configured the $------------------N and the S----------------n shares. You do this from the Share Page.... The D---a Share is configured as 'Secure' and you say you are accessing it from a Windows vm. (With Secure, you will require a login to copy/write to that share.) You do realize that Windows now requires that you log into any server with a valid user account on that server. You can find instructions for setting that up here: https://forums.unraid.net/topic/191221-some-musings-on-smb-and-samba-and-unraid-and-windows/#findComment-1561581 and continuing through the next two posts.

Please see these restrictions on Share names from the 'Add Share' help:

Docker can access the Unraid array directly through a mapping from the Docker container path variable to actual file system location ( /mnt/user/Share_Name ) used by Unraid. The user, group and permissions for access to the actual Unraid share are the subject of this post: https://forums.unraid.net/topic/188600-share-permissions-changed-to-owner-99/#comment-1540351 You must use these permissions if you want to assure that other Share Access users can access the files written by your Docker container. You are not forced to access the Unraid shares through SMB from a Docker. BUT I am not a Guru on setting up Docker containers to do this. You should probably be asking this question in the support forum for the Docker container. You should be able to find the support forum for each docker on the APPS page. (I, personally, would always choose a container that has a support thread on this forum. That way you would be expect that the container has be tested using Unraid.)

I have been using SMB and Unraid for many years now and I have never seen access to shares just disappearing from it. What exactly do you mean 'the share went dark' and where was this share? What did you reboot (Unraid or ZimaOS)? And what does the share was completely 'gone' mean? If you are talking about Unraid, are the files still on the array or pool? Where is this ZimaOS installed?

Not have a valid GUID will not take the Flash Drive offline. It means that there is another problem. Shut the server down and pull the flash drive and run chkdsk on it to see what that finds. Fix any problems and try again. IF that does not fix the problem, post up the diagnostics file in a new post.

In the GUI, MAIN page and look for 'Boot Device' then click on 'Flash' directly under that heading. If the Flash drive has a valid GUID, it will be listed here: By the way, it not unusual for Flash Drives not to have a valid GUID these days. I understand that there is a small fee for each valid/unique one issued. (You can often tell if it is valid by the fact that it looks like it is unique by having a string of numbers where I have concealed my GUID identification.) Plus, there are a lot of counterfeit Flash Drives these days because name manufacturer's product command a higher price than a no-name manufacturer! If it looks valid, contact support (get your details ready about your earlier purchase and be prepared to explain what it going on). Unraid support has always bent over backwards in helping folks who have these problems with license transfers.

I seem to remember a number of years ago when one Unraid user's server was being rebooted by his pet cat. The animal apparently was attached by the blue LED behind the switch and would 'bat' at it. (Young kids are another possibility...)

Do you have a file with the extension of .key in the /config folder of your new flash drive? IF not, do you have the old flash drive and can you recover the file from that drive? If not, do you have a backup of the that old flash drive somewhere that you could retrieve that file from? PS---- Basically the /config folder contains basically everything you need to completely recover the setup of your server as previously configured. (Be careful of using the full backup if you have made changes to the drive assignments or added/changes any drives since the backup was made!!!)

Ok, this is the thing.... So what exactly is the problem? Do you see the GUI? What is not up and running? Screenshots might be useful.

After checking for bad RAM as @JorgeB suggested, I would look at replacing the Power Supply next. PS are not just a simple brick with a transformer, rectifier and some voltage regulators any more. They are connected to and interact with the MB. (A few years back I upgraded a PS and the server started doing exactly what you server is doing. Replaced that new PS and have never had another unexpected reboot!)

One other thing to think about is deciding on a single drive capacity with a long term perspective. I have currently settled on 12TB for my systems. I have two 12TB drives residing in my storage area awaiting the day when I might need more capacity or have a drive fail.

I don't think anyone is truly making a 'bad' drive these days and your chance of getting one that goes belly up is purely a matter of 'luck of the draw'. You can see BackBlaze drive data report here (Be sure tor ead the sections where they discuss the outliers with high failure rates!) : https://www.backblaze.com/blog/backblaze-drive-stats-for-q3-2025/ In any case, if there were to be some design (or manufacturing) change that would result in a statistically greater number of defective drives in one model, by the time it was (most) likely discovered, it would already be superseded by a newer version which probably would not have the same problem. I generally purchase a new drive during a sales event and shop for the best price. I do want a NAS 'branded' drive because there is some reason to think the drive firmware is optimized for NAS operations. Whether this makes any difference for use in my Unraid server is really an unknown. Perhaps, I am just kidding my self...

Give us a screenshot of what is in this section of the MAIN page: I would suspect that there is a 'permission' checkbox there to allow formatting of disk4!

Post the diagnostics file up in a new post in this thread/topic. (New post so we know that you have added new information!)

A quick push of the power button should initiate a normal shutdown of the server down in a clean fashion.

You can also connect up a monitor and keyboard to your server as a local console. After logging in as 'root', you can get the diagnostics by typing diagnostics And look where it writes the file.