Frank1940

Got to the SHARES tab (#1). Click on the share name in that tab (#2) and that will take to this screen: Then set #3 to a value large than the largest file you will be copying to that share. Here is the 'Help' for that setting:

Yes, I do. When we get down to these type of problems, we are reduced to witchcraft when attempting to fix them. 👽 (Fifteen years ago, I often said that solving SMB/Samba issues was more witch than science. While today, that is not quite accurate, there are still instances where things are wrong buried down deep in some obscure setting where one would never think to look. That is way Small Businesses pay an qualified expert in Active Directory big dollars money each month to provide them support. )

If you have Windows 10 Pro license you should be able to upgrade to Windows 11 Pro...

One more thing. Don't use your Windows login name as a login name for Unraid. Any special permission setup for that user might carry forward and be applied to the Server. It is always a good idea to reboot the Window's Client anytime time you make a change. I don't even have a Windows Home computer. There are just too many nice features that it is missing. Proper Networking tools being one of them. When purchasing a computer, you can often find a PRO machine for just a bit extra. The difference in cost between a Home and Pro license is minimal for an OEM builder!

I have very mixed emotions about Google AI 'help'. Sometimes it is right and sometimes it is wrong. I suspect that deleting the present Windows Credentials and setting up new ones is required. (Remember to create a new credential Share Access user on the Unraid side.) This might fix the issue depending on how the extra will applied on the Windows side. If they were applied to the user or to the class/group that the user belonged to. If you have mapped a Unraid Share to a drive letter, I might suggest deleting that mapping and setting up a new mapping and don't touch the settings on the Windows side.

https://forums.unraid.net/topic/116389-access-denied-printer-unraid-share/#findComment-1058963 It is a problem which crops up from time to time. I have always suspected that it is cause because someone has attempted to control security by using Windows permissions (under the Security Tab on the Properties for the folder/file). The New Permissions utility is suppose to fix but it does not prevent it from happening in the future. I understand that the extended attributes was added for the folks who use Samba in an Active Directory environment. I will be honest at this point. I am not any type of an expert on setting Security in the Windows Environment. I open up that Window's Security tab and dread the thought that I might have to make a change! ☠️ I have put together a thread about peer-to-peer Networking and it is found here: https://forums.unraid.net/topic/191221-some-musings-on-smb-and-samba-and-unraid-and-windows The first few posts are background information. The real substance starts with this post: https://forums.unraid.net/topic/191221-some-musings-on-smb-and-samba-and-unraid-and-windows/#findComment-1561580 and continues for the next several posts.

Use this command: ls -al /mnt/user/Torrents/path-to-directory-with-problem Grab two screenshots. First of the command line itself and the next three lines. like this: Second of a file with access problems. This is all, we need to see this much of it:

What Edition and Version of Windows 11 are you running? (Windows 11 Pro 25H2 would be a typical answer. Settings >>> Systems >>> About will get to the spot on your Windows computer where you can find this info. ) Are you using Windows Credential Manager to access your Unraid Server? Why are you using Unraid's 'Secure' security setting rather than 'Private'? (Default Windows 11 Installs normally prevent connecting to a server using 'Guest' credentials but many people have turned off this setting.) Since the issue appears to be related to the Share where you store your Plex data, how familiar and comfortable are you with the Linux command line? (Don't worry, I am not going to have you run a command that would make any change to any Unraid disk. Anything that I suggest will only be to look at the file parameters!)

Because that error is not at the disk level. It is at the data level controlled by the FS driver. When you do a dd level write, you are at the disk level. (If you had introduced the 'error' via btrfs driver which is at the data level, it would have updated the checksum.) Remember that disk algorithms and the btrfs schemes are both working when you are accessing your data. And neither one are aware of what the other is doing.)

Still any time you write to a sector, you are still using the normal disk writing algorithm which will update the error correcting check sums for that entire block of data for that sector. You can't get around using it with anything that sends data via the SATA data cable. Remember the disk does not know what is being written to it expect that it is ones-and-zeros to a certain physical location on the disk. It is up to the OS and file system structure superimposed on the disk that allows the OS to interpret what those ones-and-zeros represent. The disk only reads that entire block of data and hands it over to the OS to 'figure out' what it needs from that block. A file with the famous words "Hello World" as its only data would be eleven bytes of block of (say) 1024 bytes. Bitrot has always assumed that the change happens in the actual magnetic storage media. Something changes the magnetic structure on the disk in such a way that the read data passes the error_detecting/error_correction algorithms but is not the data that was originally written to the file. Like a very high energy cosmic-ray effect... (My assumption is that when if there is a bitrot like situation, the error occurred in non-ECC RAM by some high high energy effect. Then the erroneous data is written to the magnetic media using the normal disk writing algorithm such generates the correct check sums for that data.) I understand that all of these writing/correcting software schemes are proprietary so no one has independently verified that they are mathematically flawness so there is that possibility.)

BUT using dd to write an error into the file is not bitrot because dd writes those bytes using the normal disk writing algorithm which will update the error correcting check sums.

You should get triple bonus points if you can do this. Remember, that you are only allowed to change a single bit in the file and still have the Unraid OS must be able to read the file without error. (All the disk manufacturer's have proprietary error detecting and correcting schemes to prevent this from succeeding. We have come a long, long way from the 1980's CRC detection methods and even the way that data is 'encrypted' before writing to minimize magnetic pole changes to make the comparsion between then and now. I remember that my first hard disk had a capacity of 10MB-- 10,000,000 BYTES --and cost over $400!!! The floppy disk drive only had a capacity of 360K bytes. My wife turning on the sweeper during a data write could result in a corrupted file! A flicker in the room lighting always seem to result in a corrupted floppy disk. I remember most of us turning off MS first attempt to implement the caching of data writing to disks. Its purpose was to prevent the compete stoppage of screen updating during the seconds required to do a disk write operation. There was no cache RAM on a disk drive in those days!)

Don't try and force an error! I am of the opinion that errors in files are the results of glitches during the write operation to the disk or undetected bit changes in RAM which are then written to the physical disk. In my scenario, any corruption in the magnetic data will be detected in the read operation of the physical disk. The error correction routines of the disk may fix them (Correctable read errors happen all the time and the user is completely unaware of them...) or the disk reports a read error. I am looking for the first instance where btrfs or zfs actually found an problem. And what was the outcome of the problem? A real world problem and its outcome, if you will. I have some suspicion that this FS's provide a solution to a problem is virtually non-existent.

Have you ever found an error situation and tried to fix the file. Were you successful?

I believe that XFS has the lowest overhead with regard to disk space required by the file system. ( All modern FS has provision for file recovery/data_integrity_checking built into them. The greater their capability to provide that service that more overhead they required!)