Frank1940

Look here: http://www.perpetualpc.net/srtd_resolution.html The command is not in the non-GUI version but I would think that it should in the GUI version. (found using Google 'setting screen resolution in linux'>)

There are couple things you should try. First, is a 24 hour memtst from the Boot menu. (The built-in memtst will not check ECC memory.) Second, the Power Supply. This is best done by replacement. Many folks have one in the junk box, can borrow one from a friend, or, even, 'borrow' one from a vendor with a liberal return policy. This should really not fix it. This is what UPS are suppose to protect against. The only thing that lowering the sensitivity should do is to reduce the number of transfers from mains to battery. You could make a screen shot of your UPS settings for shutdown and post it up. (Many folks haven't really thought things through when setting up a UPS.)

IT might be just the battery. You can check this with a couple of lights with incandescent lamps in them. (You want about 150W of load.) Shut the server down, plugin in the lamps. Now pull the power plug for UPS from the mains. Make sure it runs for about ten minutes on the battery. Less than five minutes and you need to replace the battery. UPS batteries for the home market UPS's are fairly standardized in size and capacity. There seems to be only two or three different ones and you can measure them with a ruler to get the size you need.

Post up your Diagnostics file. Tools >>> Diagnostics. It sure sounds like your Unraid server is not getting proper Internet access.

Can you check for Plugin and/or Docker updates?

Have you tried a different monitor? What type of connection are you using between the monitor and the server (VGA, DVI, HDMI)? I would suspect that the GPU is not getting the proper signals of the resolutions that your monitor supports and it is defaulting to something like 640X480.

If any of these problems happen with this version, try to get the Diagnostics file Tools >>>> Diagnostics and post it up in a new post with the symptoms at that time.

Anything that emits light. 🤣 Seriously, if you login via the command line, you are looking at a straight text screen. IF you are using the GUI web browser interface, it will have to using one of the default resolutions like svga.

And your point is? The Marvell controller has been giving problems to folks who are running Unraid setup for the past several years. The root cause has never really been determined but it has been rumored to be a hardware issue in the chip design, problems in the Marvell firmware or a interaction between the Linux kernel and its drivers and the chip set. As I understand it, no one--- not Marvell, not the Linux folks, not Unraid developers--- is devoting any time to solving the problem. If it is currently working in one or more of the Unraid versions for you, keep on using it if that is your choice but realize that in all probability, you will eventually have a issue with it...

For those with Marvell controller issues, you might want to read through this old thread. As you can tell, issues with Marvell are not new. To my knowledge, no one has ever pinned down exactly what is going on. Sometimes they work for some people for long periods of time and then suddenly start giving problems. https://forums.unraid.net/topic/39003-marvell-disk-controller-chipsets-and-virtualization/ The basic recommendation for some time has been, if you have a problem with Marvell Controller card (or MB chip set), quit using it. The LSI solution for plug-in cards is not that expensive these days...

Another Major release of Unraid (6.7.0) and still no proper login method that will work with the password managers. It seems to be on the inclusion schedule but never seems to make it into the active development cycle. Any idea in which future release we will finally see it?

I believe @trurl wanted these Diagnostics: Tools >>> Diagnostics Upload the resulting zip file in a new post

Googling seems to indicate that several folks have gotten the NUT plugin for Unraid to work with the Eaton UPS's. I would install it and work with the interface (I have never used NUT) to see if you can get it to work with yours. If you have problems, there is a support thread where you ask for assistance. I am assuming that you already have the Eaton unit. The plugin is 'free' so you have nothing to lose by trying to get it to work. I would not go out and purchase an Eaton when Cyberpower and APC are plug-and-play with the default plugin.

An Excellent Video from @SpaceInvaderOne on SMB shares and Windows permission issues. If you are having problems accessing shares be sure to watch this first as he goes through the 'gotchas' that are are a part of Windows SMB access. He shows as well as explains the symptoms and the solutions to these types of issues. Well worth the thirty minutes it takes to watch it even if you are not having an issue now.

Tape will probably your best solution but it is (as I recall) fairly expensive. Definitely in your case, you would want to use the Kapton tape as you don't want to have a cheap tape gumming up that backplane connector. Plus, many folks have those Molex to SATA connectors in the junk box.

You can also use a Molex to SATA power plug. These will contain no 3.3V only 12V and 5V connections.

Very interesting! Most keep this in the back of my mind. Particularly, when there are messages in the syslog complaining about IPV6 issues. I know that my IPS provider (Spectrum) is currently providing me with an IPV4 address to my Cable Modem. And I have both of my Unraid server set to IPV4 only (on the Setting >> Network tab). @nekromantik, what type of address is your IPS provider delivering to your Modem-- IPV4 or IPV6? If they are only providing you with an IPV4 address, why did you even turn IPV6 in Unraid? If you are not aware it , you also have both IPV4 and IPV6 turned on in Unraid. See Settings >>> Network settings: 'Network protocol:' Have you any other devices on your LAN that require IPV6 addresses? You manually assigned an IPV4 address (192.168.1.74) to your server. (I am not being critical of you but, rather, I am trying to understand how your setup came to be the way it was. I have no doubt we are going to see this issue again and I would like to gain a better understanding of the entire situation as I am sure that must be (and, definitely, will be in the future) situations where IPV6 addresses will absolutely be required!) Otherwise, if you had not turned on IPV6 support in Unraid, you might never have had the problem. I have a sneaking suspicion that turn IPV6 support off on the router is not a good idea. One of these days, your IPS may require its use. I understand that all of the current IPV4 addresses will map into IPV6 address space.

From what I gather you have two PC's --- The first one has WIN10 as the OS and the second PC is running some other OS. Is this correct? And that second PC does not use SMB. Is this correct? You said you used the first PC to copy the file from the second PC to the Unraid server. Why did you do this? The object was to use a separate, distinct SMB path between the second PC and the Unraid server. You have to initiate the transfer from the second PC. Itis important to realize that your network could be the cause of this problem. Your router and/or switch have either a dedicated SOC or a CPU controlling the flow of data through them. I doubt if SMB is the root cause of your problem. If it were, this board would have hundreds (if not thousands) of folks screaming...

Let's try one more test. Copy the file from the Unraid server to the PC that you uploaded it from and check the MD5 checksum again. My best guess at this point would be that there is a RAM issue on your server hardware--- but ECC RAM should catch this. (I assume that you are using ECC RAM in this server!) As I understand it, the memtst program that is installed with Unraid will not catch ECC RAM issues. But there is a version which will. You can find it here: https://www.memtest86.com/ It will run from a bootable flash drive. Be sure to run it for 24 hours. Does anyone else have any ideas of what could be causing this problem?

Now copy that same file from the first PC to the Unraid server. Get the MD5 checksum of this copy on the Unraid server. Does that match the MD5 checksum of the file that was copied from the second PC to the Unraid server?

Please reword this as I can not figure out what you did. What I asked you to do was: (1) On your PC, select a file of the type that plays correctly on the PC and not after it is copied to the server. (2) Get the MD5 checksum of the file on that PC. (3) Copy that file to a second PC. Now get the MD5 checksum of that new copy on this second PC. (4) Copy that same file from the second PC to the Unraid server. (5) Get the MD5 checksum of that file on the Unraid server. All of the MD5 checksums should be the same! If they are not, on which transfers are they different? (By the way, it is possible that could be different before and after any copy.) What we are trying to see is where file corruption is occuring. Knowing where it is happening will suggest the possible sources/cause of the problem. (You could have bad RAM in one of computers involved, a defective switch/router, etc.)

I have a suggestion for one testing mode that you might want to try. Copy a file the works on your PC to a second PC. Check both the playback and the MD5 checksum of the file on the second PC. Now copy the file from the second PC to your Unraid server. Again check the playback and the MD5 Checksum.

Folks only become aware of the problem when they have such-a-supply! Plus, any new supply will have the 3.3 volt feed on SATA connectors so a PSU replacement with a new supply will trigger the problem and suddenly a HD that worked properly does not! Unless they are aware of the potential use of the pin 3 to reset the drive, they will probably think the drive is defective. There are several options to 'fix' the issue (and none of them are truly a 'solution') but finding a PS today without the 3.3v power on the SATA connectors is probably at the bottom of the list. PS: I think WD is using these drives in the external enclosure as a way to sell them without having to deal with their earlier decision to use pin 3 was a reset line on this particular hard drive.

I would suggest that you run memtst (found on the UnRAID boot menu) for 24 hours.

You have a lot of errors in the syslog that look like this: Apr 21 05:50:05 Tower avahi-daemon[10039]: Withdrawing address record for 2a00:23c4:4e9c:5700::1f27 on br0. Apr 21 05:50:06 Tower dhcpcd[14448]: br0: DHCPv6 REPLY: Address not bound to this interface. Apr 21 05:50:06 Tower dhcpcd[14448]: br0: soliciting a DHCPv6 lease Apr 21 05:50:07 Tower dhcpcd[14448]: br0: ADV 2a00:23c4:4e9c:5700::2000/128 from fe80::4262:31ff:fe01:528c Apr 21 05:50:07 Tower dhcpcd[14448]: br0: REPLY6 received from fe80::4262:31ff:fe01:528c Apr 21 05:50:07 Tower dhcpcd[14448]: br0: adding address 2a00:23c4:4e9c:5700::2000/128 Apr 21 05:50:07 Tower dhcpcd[14448]: br0: renew in 2250, rebind in 3600, expire in 7200 seconds Apr 21 05:50:07 Tower avahi-daemon[10039]: Registering new address record for 2a00:23c4:4e9c:5700::2000 on br0.*. Apr 21 05:50:09 Tower ntpd[1636]: Listen normally on 518 br0 [2a00:23c4:4e9c:5700::2000]:123 Apr 21 05:50:09 Tower ntpd[1636]: new interface(s) found: waking up resolver Hopefully, someone who is much smarter about this type of error will jump in and give you a hand. You might not have a file corruption issue. You should compare the md5 sums for the same file on both the server and your PC. Here is one article about how to do that: https://www.lifewire.com/validate-md5-checksum-file-4037391 If you want more information about md5sum, Google md5 checksum