Frank1940

To automatically reconnect a PC to your Unraid server, use a Windows Credential. See here for how to do that: https://forums.unraid.net/topic/191221-some-musings-on-smb-and-samba-and-unraid-and-windows/#findComment-1561583 EDIT: This will connect the PC to server. It will not connect the Unraid server to the PC. Reconnecting to a 'server' that is being taken down regularly is a bit of a problem. You might need a shell script to actually be able to force that to happen.

If @itimpi's suggestion does not fix it, do this next. Open the GUI terminal window and type the following command: ls -al /mnt/user/media Post up a screenshot of the output in a new post in this thread:

See here in the manual: https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#replacing-faileddisabled-disks

And if you still have a problem, be sure you do this and post it up.

Then don't use it as a test mechanism... 🤪 Let's do all testing on a single share. And remember that rebooting/restarting the Windows clients may be required to totally refresh SMB after changes are made to SMB configurations.

OK---- I just did a test. I created a share called Test and set it up for private access. I copied one file to it. I then renamed it Test_Rename From Windows File Explorer, it remained Test Windows refused to recognize that Test had been renamed. I evened started-and-stopped the array. Windows still did not recognize the name change. I finally restarted the Windows machine and it now recognized the Test_Rename share. I copied a second file to it. That worked. Quick and dirty conclusion. Renaming an Unraid share is not a a simple trivial task if Windows is involved! You will probably have to restart both the server and any Windows clients involved.

Yes. Make sure that it covers a time period when you had the problems. You might actually run a test where you have failure and note the time and date for quick reference. give test details...

I would be having a good look at the cache drive. Let me ping @JorgeB and see if he might have some thoughts. EDIT: One more thing. What is sending this file to Unraid? (I don't recognize the format of that error message...)

Try going here: Set that #3 value to a reasonable value based on the largest file you will be transferring to that share.

1--- Post up the Diagnostics file in a new post in this thread. 2--- Give us the full name of the share with the problem.

let's start with the diagnostics file from your server. Be sure to post it up in a new post in this thread!

POst your Diagnostics file up in a new post in this thread.

I have 7 of these Seagate Ironwolf Drives (ST12000-VN0008) which I purchased new and they all are this size: I suspect that some one has overwritten the data in the NAND on the drive during the 'renewed' process. I understand that there is a lot of this type of activity going on as drive prices have recently increased and some overseas vendors are recycling drives removed from servers with high numbers of power-on hours, reflashed the NAND to make them look like they are virtually new. See this article: www.forbes.com/sites/tomcoughlin/2025/02/08/seagate-responds-to-misrepresented-used-hard-disk-drive-sales/

See here:

Begin by googling unraid.net getting rid of gpt partition and you will see that it is what is to be expected in most cases. It should be noted that parity drives for Unraid are not formatted. They only contain the calculated parity information for every byte of storage of all of the other drives!. https://docs.unraid.net/unraid-os/getting-started/what-is-unraid/#arrays-and-parity Expand this section and read: You should be able to simply assign both drives as parity drives and start the array. IF not, post up any error messages--Screenshots are always nice!

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)

No, No NO!!!! You safest choice is not to cache that share! You are in the grasp of a catch-22 situation. Don't make things worst be setting things up so that one little bit of cockpit error will result in data loss!

Not that I ever heard of...

In the User Share Setting: First Shares from GUI. Then chose the User Share (2). Then (3) using "Include disk(s):" or "Excluded disk(s):" (NOT both!) to chose where the files are to be placed.

WD doesn't day... Now also be careful not to bundle multiple SATA data cables together for 'neatness'. This can cause two problems that can contribute to UDMA CRC errors. First is that it can put stress on the cables which can cause them to loosen when subjected to vibration. Second, it can allow cross-talk between the cables which can also cause CRC errors if the cables are not shielded. PS: Always double and triple check that all SATA connectors are firmly seated anytime, you are working around any SATA cable. Last inspection should be a visual one.

Have a look at this FAQ: https://support-en.wd.com/app/answers/detailweb/a_id/15954 The point is to make sure that the cable has 'friction' when removing one without the latch. and that it is locked if you have the latch. Read carefully as apparently shroud or no-shroud is dependent on the model...

It has finally happened. In the release notes of version 7.3.0-beta 1 is this notification: This means that the reiserfs drivers are no longer available for anyone who still has disks in their array formatted with reiserfs, they will not be recognized as having a valid file system.

Since the Linux Kernel used in version 7.3.0 is now version 6.18.18, that means that there are no reiserfs drivers in the kernel. (This information should probably be included in the release notes...)

My guess would be that something has a file open in the path under that folder. (The phase "deleting that folder" is the reason for this statement– not this statement of yours: "but still I cannot write to that folder in Windows".)

@WildWayz, you can verify which user is connected by running the following command on your Unraid server using the GUI Terminal. smbstatus