remotevisitor

Using the command xrandr ... OK system: AMD A10-6800K APU with Radeon™ HD Graphics @ 4100 MHz shows Screen 0: minimum 1920 x 1200, current 1920 x 1200, maximum 1920 x 1200 default connected 1920x1200+0+0 0mm x 0mm 1920x1200 0.00* while the problem system: AMD A4-3300 APU with Radeon™ HD Graphics @ 2500 MHz Screen 0: minimum 720 x 400, current 720 x 400, maximum 720 x 400 default connected 720x400+0+0 0mm x 0mm 720x400 0.00* They are connecting to the same monitor.

I have 2 unRaid servers running 6.7 which are connected to the same monitor via a KVM. One server displays the GUI at the normal high resolution of the monitor, and the other server displays the GUI at the low resolution. Several releases back both displayed the GUI at the normal high resolution. Although I do suspect that the response the monitor gives to its capabilities, it possibly also depends on the something in the video driver,

Well looking at the list provided 2 posts back I would say your problem is whatever is writing to the /var/log/atop directory.

And there lies the problem. You see this as a single operation, but in reality it is 2 operations at the file system level: create/open file seek to file position required to allocate file of given size. In order to create the file Unraid has to choose on which drive it is going to create it so by the time the file seek operation comes along the disk has already been selected; hence the need for the minimum free space setting.

I have 2 SASLP cards in my system and I suffered disk dropouts, but only with my WD 6TB disks (I have a variety of disks from Seagate and WD from 4TB to 10TB). Now I seem to remember some posts when the Marvel controller problem was identified as the cause that there also appeared to be some correlation with specific disk manufacturer/size/firmware (which possibly explains why some people have problems but others do not). On my system I tried setting all my WD 6TB disks to never spin down and this appears to stop them dropping offline. Now this is only a workaround of the problem, and might be specific to my system, but it may be worth trying until such time as you are able to replace the SASLP cards.

This information comes from the BIOS on the motherboard and there are several reasons to explain the discrepancy: The documented spec is correct and the BIOS incorrectly reports the wrong size. The documented spec is incorrect and the BIOS reports the correct size. Unraid for some reason is misinterpreting the reported size. Now I suspect that in this case it is probably option 2; When the motherboard was first released the BIOS probably did only support 16G and matched the specification. However (assuming this may be a version 1 of the motherboard) the F8 version of the BIOS suggests there was a change in the supported memory capacity if you look at the release history for the BIOS: https://www.gigabyte.com/Motherboard/GA-P55-USB3-rev-10#support-dl-bios. This would then explain why the specification and reported size by the BIOS differ. However it is impossible to be 100% certain until you try it.

Do you have a file/directory that starts with a "-", in which case the "*" will be expanding to something that looks like a command option. ? maybe ‘chmod -- 777 *’ might work in that case.

My understanding of the crontab entry the parity check entry is set to run on the 1st to 7th of the month and each Saturday; It is not the 1st Saturday of the month.

‘wrong csrf_token’ errors are due to you not closing all browser pages to your Unraid when you rebooted the system.

On the contact page you used, scroll down on the page to the ‘Contact the Unraid Team’ and enter your details/message for the support team.

Have you seen the new Parity Check Tuning plug-in (requires UnRaid 6.7 rc3 or later)? It doesn’t limit the speed but does allow you to split parity schecks on a schedule when the system is likely to be less active (such as overnight)

Quick question about your Flash drive .... is it USB 2 or USB 3 and/or is it plugged into a USB 2 or USB 3 socket? In theory both should work, but more people seem to have problems with Unraid when using USB 3 drives or sockets, so the advice is if possible to use USB 2 if you can.

Have a look at the Unmanic docker ....

When a new drive is added to an existing parity protected array, unRaid will write zeros to the whole of the new disk before it actually adds it to the array; This ensures that parity is correctly maintained. so to answer your question, it is only the new drive that is written to when it is added to an existing array.

Try

Perfectly normal temperatures for disks. You usually start worrying when they are around 45C or higher. (I’m sure people will chip in with their own opinion on what temperature best not to exceed .... but your 33C is perfectly within expected operational range) If they used to run a bit cooler in your system it could just be dust and fluff on the air vents and fans which need cleaning to improve the air flow through the system.

/mnt/user0 only contains the files/directories on the data disks. /mnt/user contains the files/directories on the cache and data disks. usually you want to use /mnt/user unless you are doing something which must exclude any files that happen to be on cache disks.

The permissions on a file affect whether a file can be read/written ... and deleting a file is neither of those operations. Rather it is the permissions on the directory containing the file which controls whether a user can delete a file in the directory .... the user deleting the file must have write access to the directory containing the file and execute permission on all parent directories. So you need to be looking at the permissions and ownership of the directory containing the file to be deleted not the permissions on the file itself.

If this folder is actually a share then all you need to do is go to the share tab in the web UI click on the share and set ‘Use cache disk’ to ‘yes’. This will invoke mover once a day (unless you change the default schedule) for this share and move the files from the cache drive to the array. job done.

The ones with the higher capacity probably have files on the cache drive (notice they have an orange triangle icon) , so the cache drive size is being included in the size calculated.

You probably have to give the full path to the command, eg /usr/local/sbin/mover stop

Have you checked whether Windows thinks your network connection is a public (untrusted) connection rather than a home (trusted) connection? windows usually asks what sort of connection it is the 1st time it connects to an ‘unknown’ network ... if you had answered this prompt wrong then windows will be blocking services on your local network because it considers them insecure.

Have you tried booting in Safe mode from the boot menu to make sure the problem isn’t caused by incompatible plugins in your config directory?

If the files are in the same location on different disks the you could look at using the script here to identify them all:

Shutdown your Unraid server, remove the flash drive, plug it into your Linux/MacOS/Windows machine and copy the license file into the config directory on the flash drive. Unmount flash drive, plug into Unraid server and power on.