stebwen

Hi everyone, unfortunately i had to spend the whole evening yesterday to figure out what the problem is. So hopefully, this post helps someone who is discovering the same issue. And maybe an expert can give a statement to this, because the problem is still there, i just know how to handle it for the moment. Here is the situation: I shut down my server yesterday after a long period of uptime (about 100 days) to insert a graphics card (Nvidia GTX 1060). After rebooting, the GUI (over LAN) was not available anymore. - that is basically the whole problem. SSH worked perfectly (important later). What i did not know at that time, the GUI (over LAN) returns to work, it just takes a long time (over night). - i already discovered this some time before, but there it was like 10 mins or sth, then the GUI was there again; this time it took too long in my opinion - So i startet to search for the issue: 1. GPU in and out - same problem 2. Localhost GUI - same problem (no networking issue) 3. all dockers off, all VMs off - same problem 4. boot in Safe Mode - everything fine (plugins?) - side note: GPU is perfectly detected in Safe mode, dockers working, VMs fine In safe mode i installed all plugins back in... everything fine - weird isn't it? Ok, all plugins deleted in /boot/config/plugins Normal startup - fine Result: it is the "Recycle Bin" plugin that causes the GUI to start up with a very long delay! System: 6.9.2 Recycle Bin: 2021.08.14 So, here are my questions to the whole thing: - in the plugins folder i discovered some files like: ._unassiged.devices.plg / ._recycle.bin.plg is that supposed to be like that or does the system need them? - there is a folder /boot/config/plugins-error - this one contained the unassigned.devices.plg, why is that? the Unassigned devices didn't cause any problems - is there a reason why the recycle bin plugin needs so much time to start up? - My first thought was the "Update Recycle Bin Size in Background" feature: but turning on/off makes no difference for startup - why does it prevent the GUI from responding? - what are those running tasks about? - /usr/bin/du -shc /mnt/..... AND find /mnt/cache/exchange/.Recycle.Bin I looked into "htop" over SSH while the GUI was not available and discovered some tasks (see screenshot) that seem "to work for the recycle bin" and causing a relatively high CPU load (nothing else started) Thanks in advance to experts for answering and i hope this documentation helps someone else.

this is something that i recognised generally when working with mac OS. AFP performs better, but is not recommended anymore and will be gone in the next UNRAID version. How can I tune the SMB for mac OS? Do you have experience there? Is there a plugin? I have no idea how this could work to tune SMB? Thanks for any recommendation. Should we open a new topic?

Hi KRF, im also using mac os and i had lots of problems in the beginning using UNRAID. What surprised me, is that the cache drive didn't speed up transfer very much. Which is the same for you... What i found out while testing is, that the transfer speed strongly depends on the protocol. I assume you are using SMB... because it is recommended. The weird thing about this is, that apple itself recommends the SMB over AFP, but AFP is much faster with the current UNRAID version... Another important point is, which files are you transferring? -> i always tried with a 7 GB .iso image (this gives faster speeds than a lot of small files) From SSD (Mac) to SSD (UNRAID) over a Gigabit network i got the following speeds: - AFP: full speed, around 110 MB/s which is perfectly fine (theoretical 125 MB/s) - SMB: everything between 0 and 120 MB/s - SMB seems pause every few seconds... results in around 70 MB/s in average -> on a windows machine this is stable I also found out, that in the next Version of UNRAID: I think i tried "beta30" - the SMB integration is FASTER than at the moment and AFP is completely gone (as expected from the recommendations) ... so i hope this helps you a little... i know its not really a solution for now... just sharing some thoughts, ideas and measuring.

False alarm, im sorry. Status update: I replaced two of my drives (in an array of 5 disks) to bigger ones. One was already showing a SMART warning. The problem of crashing UNRAID is gone now.

Hi, i also got frequent Unraid crashes... so far as i found out, it always happens when the last disk spins down. Don't know why it is like that, but setting one disk (i chose parity) to "never" spin down helped me. The crashes are gone now. Maybe this helps you too. I know its a workaround, but for now its fine. I have read another thread where it was reported to be a power supply problem... for now i don't have another PSU to test, so i'll stick to the method.

did you find an answer to your question? or have you tested it? does it work properly, Apples time machine with the Unraid cache? thx in advance