Frank1940

The one that I can see is that you will have to perform a parity rebuild on the entire array! That is a about 2-3 hours per TB of parity size.

I would suggest that you post about the problem in the 'Support' thread for this Docker. You can find it by clicking here:

You can run Unraid 100% of the time and run WIN10 as a VM. Here is the section of the manual for VM's. https://docs.unraid.net/unraid-os/manual/vm/vm-management/

To add a bit of info to what @Squid said, go to to the DOCKER tab and click on the icon for the Docker container you want to change. You will an 'Edit' choice in the dropdown box.

Have you seen this thread and the sub-forum that it resides in? https://forums.unraid.net/topic/146818-optimal-samba-settings-to-get-better-macos-to-unraid-performance/#findComment-1318928 Mac SMB issues seem to be common and I really have no particular advice to offer beyond pointing you to this section of the forum.

Try posting in the support thread for the Docker that you are using. (Click on DOCKER tab than on the icon for the Plex Docker icon and look for the 'Support' in the dropdown menu.)

Start with this post and read the next two after it. https://forums.unraid.net/topic/77442-cannot-connect-to-unraid-shares-from-windows-10/page/10/#findComment-1494016 Now, you are using Linux. How are using networking to the Unraid server--- NFS or SMB/Samba? If you are using SMB/Samba, you should probably read this post: https://forums.unraid.net/topic/110580-security-is-not-a-dirty-word-unraid-windows-1011-smb-setup/#findComment-1009109 You might want to download the PDF file as it has a lot of general information in it about how SMB things work in Unraid. I have a fair amount of knowledge about what goes on with Windows/Unraid SMB but no real experience with Linux/Unraid SMB. I don't think there are any major problems as I have not seen a lot of posts about issues. (But I suspect the Linux SMB world is much more lenient about enforced security than Microsoft is in the Windows world. (What I mean by that is that Linux expects the individual system administrator to set things up so they are sufficiently secure secure for his environment where Microsoft is taking the lead and making SMB as secure as possible wherever it is installed. (They are using one scheme fits all whether is a home network having a server and one client PC or the Pentagon with a few thousand servers and, perhaps, a hundred-thousand clients transferring top secret information via SMB!) EDIT: You should be able to run the New Permissions tool and it may address your problem. You could tell this by using the ls -al /mnt/user/{path-to-problem} command to check the owner, group and permissions of the directory and the files inside of that directory

Read the December 4th 'EDIT' in this post: https://forums.unraid.net/topic/110580-security-is-not-a-dirty-word-unraid-windows-1011-smb-setup/#findComment-1009109

Second thought. Run New Permissions again that Share again. (Not being able to see inside that directory may have prevented it from fixing permissions and owner/group...)

Can you write to the other folders in this share?

It has been a long, long time since I looked at split levels but I am wondering why you are even bothering with it. I am assuming that you want the movie and its folder on the same disk. Well, that will happen automatically. You should have set the Minimum free space: parameter for the share to be about 25% larger than the maximum size file you expect to save there. Even if there is more than one file in the movie folder, it only takes a modern HD about 5-6 seconds to start sending data from a cold start. (This parameter was added back when folks were saving DVD's in the folder-and-file format with 3-to-6 .VOB files making up a complete movie on 100-500 GB disks. These .VOB files are all exactly the same size (1,073,739,776 bytes) and must be seamlessly streamed as the break between files can happen in the middle of a spoken word!) Plus, with the size of HD's today compared to even HD movie files, the odds of files being split are very, very small.

Try running the New Permissions tool ( TOOLS >>>> New Permissions ) on just the Share that has the problem. (It sounds like there is a 'bit' mis-set in that directory/folder's permissions.)

I know this is not what you want to hear but read this. (You don't have to read the entire thread but you will quickly see that there are a lot of issues with trying setup and maintain a list of compatible flash drives.) https://forums.unraid.net/topic/119052-psa-on-sandisk-usbs/ Be careful of the vendor as some (amazon, for one) put all items with the same UPC code into one bin. So that bin may contain both genuine and counterfeit parts from several different 'sellers'. What you get when you order is the luck of the draw regardless of the vendor you might think you chose!

See this table from this post: https://forums.unraid.net/topic/131730-update-from-69-to-6115-and-got-permission-denied/#comment-1219731 The problem comes because Unraid needs permissions of 666 for files and 777 for directories. Many Dockers set the permissions for files that they generate as 644 for files and 755 for directories which means that 'group' and 'other' do not have write permissions. The UMASK variable of 000 will fix this. The PGID sets the proper group for Unraid Samba to work correctly. EDIT: December 5, 2024 Let me expand on this a bit as it may help those with permission issues understand how Unraid has configured Samba in Unraid. I have gleaned this information through analyzing what things work and don't work. A forensic investigation if you like. This investigation indicates that Samba (as LimeTech has it setup) uses the group permission for most Share Access user access. Look at what the default owner, group and permissions are for files written directly from a Windows PC writing files (over a period of time) to the array: Notice that there are three different owners for this group of three videos and their files--- smbuser, user and nobody. There is only one group--- users. If you do some investigating, you will find that all three of the 'user names' are members of the 'users' group. Note that the permissions are identical for both owner and group-- rx- I can assure you that this share is Private and users 'smbuser' and 'user' can have full read/write privileges to all of these files regardless of who owns them! The only way that this can happen is because that LimeTech has set up Samba in Unraid so that it is expected that the file access will be controlled through the 'group' privileges/permissions-- not through 'owner'. The same argument might be made for those connections are using the Guest access when accessing public shares. They are using the 'other' permissions. This is the reason that underlying Linux Permissions must 666 for files and 777 for directories.

Run the New Permissions tool ( TOOLS >>> New Permissions ) on just the Share with the problem and see if that fixes it.

This often happens when you are working in the area of the SATA cables. You will disturb one of them enough so that its locking lug disengages. (I have always said that the SATA cable design is the poster child for how NOT to design a connector system!) A good rule is to check and double check every SATA connector after working on the inside of your server case before you button it back up.

@Kilrah, thanks for another failure mode from inactivity. I just now recall an experience with a 10 or 20MB hard drive (that size is correct!!!) back in the early 1990's. It became so slow in spinning up to speed (hardening of the lubricant) that it would not be ready when the BIOS went looking for it to start loading the OS. My solution was to do a complete read/write check of every byte of memory (640KB) as a part of the BIOS startup process. That took long enough that when the BIOS did go looking for the hard drive, it would be ready. (Replacement of the drive was about $400 back then...)

I would imagine that the lubricant used on the spindles has hardened which prevents the spindle motor from being able to spin the platters up. Exercising the hard drive by periodically spinning up the drive may prevent this from happening. Any mechanical device that moves will eventually seize up without periodical movement of all its moving parts whether it is a steam engine or a pocket watch.

This is the second Bump post for the section labeled "EDIT: December 4, 2024" to the first post of this thread.

I used rsync to backup 18TB of media data from a working to a backup server. This is the switches that I used for rsync: rsync -avhPX You can google for more info on what each switch does. Also be sure that you understand what the trailing slash--- / ---does on the source path and destination path. (It does not make much difference for most Linux commands but it does for rsync!) P.S.--- The same command will also update the backup with any new or changed files. You may not have need of this right now but keep that factoid in the back of your mind. (The switch is missing that would delete any files in the destination directories that have been removed/deleted from the source directories.)

Put the flash drive in your PC. Now look in the root of that drive for the config folder. Inside of that folder is where you will find those files!

You should be able to do by adding the following to the Samba Extras section of the SETTINGS >>> SMB [global] server signing = auto (If there already is a [global] section heading, just add the second line.) I test this by upgrading a WIN11 Pro mini computer to 24H2 and verifying that SecuritySigniture was required. (I had to turn it on-- not sure why??) And everything worked. Note that there are TWO major security changes in 24H2 update. The second one is that guest logins from Windows clients are no longer permitted on WIN11 PRO (and probably the Enterprise and other specialty versions). You can get around this by adding a Share Access User to Unraid and setting a Windows Credential (type that phase in the taskbar search box) for your Unraid server and the Share access user that you set up. (P.S. You do not need a separate credential for each Windows client computer if they all have the same Share access privileges on the server. If you are coming from using Public access mode on your Unraid server that is what you had anyway!) That Share Access user is basically just a set of rules and any client computer can use that set of rules. SMB and Samba prefix the Share Access user with the Device Name for that computer. You can find that in the Settings app as shown here: Because of this combination of the Device/Computer name and the Share Access user, each login from separate client computers becomes unique and everything just works. If you look at the devices on your router, you will find it there. (By the way, that name should be unique or things don't work right...)

Look at that Share settings SHARE >>>> [Share-name], the 'Minimum free space:' parameter is set to 781.4GB. Reset to something more reasonable-- about 25% larger than the largest file you expect to upload. (I have mine set for 50GB.)

If you have write permission turned on to the share(s), you are still at risk. Most of the time, the Malware will be installed on one of the client computers. As soon as you connect to the server, it has all the info it needs to do its work. (By the way, Windows SMB clients stay logged into the server until one of the two is physically powered down!) You need to do a lot of googling with the information that you have (or can discover through investigation) about actual Malware software you have to find out how to clean the malware from your entire system.

Try it without the share being 'hidden'. (I seem to recall that there have been other users with issues when using hidden shares.)