Frank1940

You are right. There is a possibility that the folder may not to shared when first created. (I had mixed results when I was testing just now on a second WIN11 computer and now I can't get back to the case when creating a new folder that it is not already being shared. Double razzinfrass WINDOWS!!!! Both computers now create new folders are shared when created.) If it is not shared (and it will say so on that Sharing tab of the folder's Properties) , click on the 'Share' button. Then left click on the name in the box to highlight it and click on the 'Share' button. I am not a Windows IT Professional and I have used Google a lot to gain what small insight that I have about how Windows networking works under the hood. I have learned just about enough to make me really dangerous. And I know from my previous experiences at least 50% of the 'solutions' on the Internet don't work...

OH, I hope you are using an Windows user account with Administrative Privileges to set things up..

The Network Neighborhood folder I created per the instructions is not automatically shared like shown in the sceenshot in the "Unraid & Windows 10 SMB Setup" pdf referred to above. Here is a screenshot of that part of the instructions: You are now done with the Network Neighborhood Properties. Click on the 'X' in the upper right corner and close it. The only thing we needed was the 'Network Path:' to this folder and it is on the Windows Clipboard. We now move onto this step: Below is a screenshot of the left pane of Windows Explorer with an arrow indicating where to right click: Then follow the remaining instructions. ================================ +++++++++++++++++++++++++++++++++ ================================ By the way, you can use the Network Neighborhood folder that is on your desktop to access your server. Just double click on it to open it and double click on the shortcut to your server that you created earlier. You do not have to integrate it into Windows Explorer but that step is a very convenient feature. One more thing. Make absolutely certain that your Connection (Wireless or Ethernet) is set to 'Private Network' as shown below: The 'Public Network' setting is for connection to network in Public places-- WiFi hotspots, McDonald, motels, airports, etc. It is much more restrictive in permitted activity. I also use 'Sleep' for my Media servers and I can tell you it is a bundle of snakes. The standard Windows built-in sleep setup just did not work right for me. To be honest, it was not a network issue but audio issues in that it would refuse to properly recognize my AVR when it woke up. The solution was found after several days on Google and a bit of a kludge but things seem to work now. (I think it was actually going into some type of hibernation mode rather than a true sleep mode.)

See here: https://www.linuxquestions.org/questions/linux-newbie-8/what-is-in-drwxrwxrwx-915243/ The 'New Permissions' Tool in the TOOLS tab will fix these problems. However, you also need to figure out what program generated these directories and fix the write permission settings on those computers. (I would be a bit suspicious that some one has set up permissions on a share from Windows: This is a quote from a section of a Post: This quote comes from this post: https://forums.unraid.net/topic/110580-security-is-not-a-dirty-word-unraid-windows-10-smb-setup/#comment-1009109

This is the big problem that the Network Neighborhood is intended to address. Windows SMB no longer properly detects all of the servers that are on the Local Network. (As explained in that PDF document, this condition has existed for several years.) In fact, as I recall, even back then, there would be times when servers could take up to forty minutes to appear under Network. (SMB was introduced back when 386-20Mhz CPU was the King-of-the-Hill and polling times were set to tens of minutes to reduce the overhead on the CPU!) Are you leaving the server on 24-7? This seems to help. I put all of my Windows Media players (Windows 11 pro, 23H2) to sleep and they never have problems being connected to the mapped drive to the media files on one Unraid server. And once the clients are awake, I have never had a problem connecting through my Network Neighborhood. (Basically, I have four servers on my network-- two Unraid servers and two Windows 11 pro computers in a peer-to-peer configuration.) All shares are private. Share access is mostly read-only because I worry about Ransomware attacks. There are two desktop computers which my wife and I use on a daily basis. Those computer are shutdown at night and restarted in the morning. Again, they have not had any issues in over two-and-half years with file access. Both of them connect to a shared address-book database on a mapped drive to a folder on one of the servers. You seem to have only one server and, perhaps, the Network Neighborhood concept seems a bit of overkill but if it works, so be it. (In the past, I have often said that solving SMB problems is more witchcraft than science!) Get things working using the simple possible setup and make sure that it continues to work for a few days. Than try the more complex setups/situations one at a time and verify that nothing has been broken before going on. Try turning off sleep on your desktop and see if the problem clears up. (I created a desktop shortcut to put the Media computers into sleep mode and pinned it to the taskbar. But I found out that for this to work properly, I had to disable the hibernation mode. But that is a story for another day.)

I suspect the problem is on the server with the Linux permissions to those folders that she is having the problems with. There are a couple of approaches that you could try. IF you want to investigate and troubleshoot the problem, use the GUI terminal (the icon on the right side of the GUI Taskbar). Type the following command: ls -alh /mnt/user Look at the listing. You should see something like this: Column 1 is the permissions d = directory; r = read; w= write; x = execute; (a ' -' in place of the 'd' Indicates a simple file) The permission letter is means the permission is on. a - means the permission is off. The first block of rwx is for the owner, the second group is for group, and the third group is for others. Column 2 is the owner Column 3 the group Column 4 is the name of the resource. (Partially obscured..) Hit the <up-arrow> key and the command will reappear. add a / and the name of the share that the problem folder is in and hit <Enter>. Repeat until you get down to the directory/folder with the issue and look at the permissions. These are the permissions that we expect to find for directories and files in a Share. (Quick explanation. When you setup your wife as a Shares Access user, that means that she automatically becomes a member of the group 'users' and she actually gains access to directories and files through the group permissions.) IF you just want to fix it. Run the New Permissions tool in the TOOLS tab. Run it on the Share with the problem. If this does not fix it, come back with what you are seeing when you us the ls command. EDIT:: Linux is case-sensitive so you must type all Linux commands, resource names and parameters using the proper case!

I download your Diagnostics. Are you exporting many of your shares as 'Yes-Hidden'? (I am not familiar with the code for hidden SMB shares but I don't recognize that code in the diagnostics...) If you are, un-hide them until you have everything working! (Linux is case-sensitive and that make a big problem for most windows users!!!)

Did you setup the Network Neighborhood in Windows? Can you access just the server through Windows Explorer? To access just the server directly through Windows Explorer, you type the following in the Address Bar window of Windows explorer: \\{server_name} You should then see all of the shares that you have set up and exported on that server. You will only be able to access those shares that you have been granted access permission in the Unraid Share setup tab. By the way, I would not be setting Windows credentials for both the IP address and the server name at the same time. (I have not been able to access the server via the IP address for the last several Unraid versions and Windows updates. [ I use server_names for my Windows credentials.] I don't know what is going on but I suspect that backdoor may have been blocked.) Remember that Windows will only allow one connection from a client computer to each server. Once you establish that connection, any attempt to establish a second connection will fail with some sort of error message. And, often, that error message will not be a true indication of what the problem really is! That is one thing that makes troubleshooting these problems so very difficult. Before you get upset about this error situation, remember that MS is not only dealing not only with the error codes from the Unraid OS but every other server OS that exists! Personally, I don't like to type long path names on the Address Bar. Too easy to make a mistake. I start with the server name and drill down the tree. If there is a particular share (or a folder within a share) that I constantly access, I setup a (Windows) Mapped Drive and have it connect at startup. (Of course, the Network Neighborhood type of setup makes this easy!) IF you are using a wireless connection, make sure that this setting is on 'Private network'. You can change it by clicking on it.

It is not the owner that is being changed to haldaemon from users , it is the group . The owner is being changed to 82 from nobody . The thing that I noticed is that the appdata directory in not in /mnt/user which is where I would expect it to be. Whether that is a problem, I am not sure. Perhaps, you have an explanation as to its present location. Often when we find these type of owner, group, and permission issues, it is a Docker (or, perhaps, a VM) that is the culpit. If a docker is to be writing to the Array, these variables should be defined as follows: PUID = 99 PGID = 100 UMASK = 000 PUID of 99 equates to nobody PGID of 100 equates to users UMASK = 000 sets full read/write permissions for directories and for files. Looking at the name of haldaemon you should be aware that a 'daemon' is a term that is given to a process that runs in the background. I would suspect that the 'hal' might give you a clue about where to look.

Go to the BIOS during startup. Look to set up the boot order so that the BIOS actually looks for your thumb drive and make it the first device that it tries to boot from. Sorry but every BIOS is different so I can't give more specified instructions...

Quick thing to try. Put the the thumb drive in your laptop running Windows. Look for the directory in the root of the drive that begins with EFI Rename it to either EFI- or EFI depending on its present name. Now try and boot your Unraid server.

Personally, I would run a non-correcting parity check first to verify that all of the disks can be currently read. If that runs without an error, I would replace the parity disk and add the two new data disks. After parity rebuild and the formatting and clearing of the new disks, I would use the newly configured server for a month. This will verify that there are no infant mortality problems with the new disks. (You want to do this before the vendors return window expires! In fact, I would run another non-correcting parity check just before expiration....) Then replace one of the old data disks. Replace the second disk after a couple of weeks. (Store the old data disks for at least month after that. They are an emergency backup of your data!) (I am a bit paranoid and take more caution than many folks do but I worked in my prior life as a engineer and got my fingers burnt a few too many times when it was assumed that everything would go smoothly! In fact, one of things that I learned is that, if you planned for things not to go smoothly, any problems encountered were more easily corrected.)

I would do it basically as you have planned. The only thing I might do is to preclear that 14TB while you rebuilt parity on the new 16TB drive. Then when you add it as a new data disk it will be ready for use as soon as it is formatted after you added it to the array. (Notion the underlined AFTER!!!)

Disclaimer: I don't use Wireguard. But since you have asked for help and not gotten a response from anyone else, here is a link to Wireguard in the Manual: https://docs.unraid.net/unraid-os/manual/security/vpn/#support If you have already found this, there are some links at the bottom of this manual section to Forum Threads that discuss Wireguard issues. Perhaps, a request in the one that seems most appropriate to your problem might get a quicker response.

Connect a monitor and keyboard to your server. Now boot up the server. At the bottom of the monitor screen just above the login prompt, you will see your IP address. Write it down. Now login using root and your Unraid password. Then enter this command: diagnostics Note where the file is saved. Then push the power button for about one second and the server will power down. Pull the flash drive and upload the diagnostics file in your next post. Now look at that IP address and compare to the base IP address of your new router-- Not the Internet IP address. The first three groups of numbers should be identical. (If they are not that is probably where your problem is.)

Tell us about your Windows side of the equation--- Windows 10 Pro, 23H2, etc. Make sure that your Windows Network Profile is 'Private' and not 'Public'... (Many of these problems are on the Windows side of the equation. MS caters to the corporate world and to them security is paramount. MS is now dedicated to keeping Windows clients from connecting to any suspicious server!) There is a white paper about how to set things up for Windows 10 and everything in there seems to work for Windows 11. You can find it in the first post of this thread: https://forums.unraid.net/topic/110580-security-is-not-a-dirty-word-unraid-windows-10-smb-setup/ Since you seem determine to not to post up information because of privacy concerns, you may have to work through things on your own. Unraid will work reliably in the Workgroup mode if both Unraid and the Windows clients are set up correctly. (Using Active Directory is definitely more of a challenge!)

CRAP! I forgot one thing! Go to SHARES Then Click on each share tyou want to access with that user (that yoiu setup in the previous post: Scroll down until you find these sections: Step 1 --- Set the Security you want for this share. (You can click on "HELP" icon on the GUI taskbar for help with the settings!) Step 2-- Set the Access for that share for each user. Step 3-- Click "APPLY"

Try creating a Windows Credential using Credential Manager for that new user and user password that you used for the mapped share. (You may have to reboot the Windows computer to test...)

The permissions on Directories should be 777 and on Files 666. For access from Unraid shares, (From my experience on recent releases) is that the owner of a resource is not the key, it is the Group (which Unraid expects to be users and that any user who wants to have access to a resource must also be either the owner or a member of users. The easiest way to become a member is to added as a 'Share Access' user under the USERS tab of the GUI. Futhermore, all Dockers apps (and, I assume, VM's) that write to Unraid Shares should have these parameters as follows: This information comes from this posting: https://forums.unraid.net/topic/131730-update-from-69-to-6115-and-got-permission-denied/#comment-1219731 EDIT: Actually in a secure environment, much of the access to a share will be through being a member of the Group. That is way why it is necessary for the members of the Group to have full access to any resource.

You never really stated how you shutdown your Unraid server or how you found that the flash drive had failed. One of things that happen when Unraid shuts down gracefully (or 'cleanly'), it sets a flag in a file on the flash drive to indicate that the array was shutdown properly. (i.e., all of the cache buffers were flushed to the platters on the hard disks.) When your drive failed (or was corrupted), this flag may not have been set (or you didn't restore the file that contains the flag.) What happens when Unraid boots up is that it checks for this flag. If it does not find it, it assumes that parity is not correct and offers to rebuild parity. The GUI informs you that starting the array will start a parity rebuild. (Long experience has shown that this is usually the best option for most unclean shutdowns if all of the data drives can be mounted.) This rebuilding parity check may or may not find any parity errors. (There were discussions in the distant past as to whether it might be better to run a non-correcting parity rather than a parity rebuilt. The problem was that if the non-correcting check found an error, it was almost impossible to find a cause-- and a solution --to fix the problem. So a slow consensus was reached that rebuilding parity was the way to go. That way, if there was a subsequent disk physical failure, that disk could be rebuild without a loss of the data on that disk--- Even if there was a data problem on another disk, that first disk with the failure could still be successfully rebuild. If there was a case where parity could not be rebuilt, the disk with the problem would be revealed and that issue could then be addressed!) I would assume that all of your data on the data drives are OK unless there was a disk write operation going on when you actually shut the server down. Most of the time, data losses occur when the server is forced down by a power failure. I can not recall a data loss from a simple flash drive failure-- unless there was subsequent cockpit error. One thing you should worry about is assigning a data disk as a parity disk. (Rebuilding parity onto a data disk will result in data loss.) But I would assume that you have already figured out (or knew) which drives were your data drives! If you don't, state so as there are ways to figure things out.

Here is the section in the Manual about replacing the flash drive: https://docs.unraid.net/unraid-os/manual/changing-the-flash-device/ Not that I am aware of. Unraid in its basic configuration is fairly hardware agnostic. However, once you are using VM's, you will probably have to change things if you are passing hardware through to the VM. (If you pass hardware through to a Docker, the same warning will apply. Much less likely with a Docker but I would bet there are a few Dockers which do use passed-through devices.) OH, make screenshots of the tabs for disk assignments, network setup, Docker, plugins setups, etc. If you do, you will never need them... 👿 If you need more help, please provide more details about what you currently have and what you are doing with your present setup. Then tell us what you would be proposing to do with the new setup.

So what are those permissions? (A screenshot using ls -al command in the Terminal GUI would be very helpful.)

Try writing a file size larger than 5GB. Depending on what the process is that is figuring your write speeds, the time may include a lot of time that is not actually the file transfer itself but may include things necessary to set things up for the transfer. Unraid Share file allocation process is particularly slow as it adds another layer of software to the normal Linux file creation. I looked at your shares and it appears that you are caching writes to your shares. Normally, using a SSD (or NVME) cache drive for a share will take good size files speeds close to 1Gb/s speeds. Also try using the 'Write-reconstruct' option as shown below: IF trying these does not work, post back with what you tried and what were the results. One more thing, have you checked the speed transferring a large file back to your PC?

Have a look at CA User Scripts plugin which can be found by searching APPS tab...

Many long years ago, I had a transfer problem from Windows to my Unraid server. I spent the better parts of two months trying to figure out what was happening. One of the things I finally tried was to update the Realtek driver on my Windows computer. That fixed the problem! This solution is one that it probably outside of the 3-Sigma limit but it is something to consider. (Just be sure that you go to the MB manufacturer to check to see what version they recommended for your MB. Update if they have a later version.) RealTek has had driver problems for years. Windows is generally better off than Linux but they are the low-cost supplier of NICs and their driver software fits that niche.