ph_

Regarding the ingredients, seems those do not get installed by default. The solution can be found in the developers documentation: https://wger.readthedocs.io/en/latest/commands.html#create-settings after installing the container, open up the container console and type: wger load-online-fixtures download and installation takes a few mins. when searching for ingredients in the app, you can find the entries, however Ingredient overview still shows nothing. Best.

HI, thx a lot for your post - really helped in reinstalling my overleaf instance! In my case I ran into one small issue in step 5.1 - tlmgr was not found . Made sense as the custom path did not contain the texlive installation, so I followed the "UNix ish" instructions here for a fukll installation: https://www.tug.org/texlive/quickinstall.html. What they do not really explain is, that the path you also use in your pathfile is the default installation path for texlive. so you choose a random temporary folder for the download, e.g. \usr\tmp then the actual installation will by default save the packages in /usr/local/texlive/2024/bin/x86_64-linux I did not quite understand though why you named the path to the .sh script "/mnt/user/appdata/overleaf/set_path.sh" . Actually after setting it in the template, I could neither overwrite the created folder with the actual script file, nor could I delete it for some odd permission problem. I solved it by putting my set_path.sh file into that folder and changed the command itself to: chmod +x /mnt/user/appdata/overleaf/set_path.sh/set_path.sh. I guess this could be done more elegantly, but it works. Finally, the tip with tlmgr add path was gold! Indeed I had problems with biblatex , too and was not able to get the bibliography to work . Now all seems fine. Brilliant! EDIT: once I changed further things on the template (added a few variables for email / smtp) and rebuild the container, I noticed that my projects would not compile any more for various reasons relating to missing files in packages etc. I went on to go through the whole process described above again as seemingly it did some needed changes to the container which were needed after all. I then commited all the changes to the container, however, oddly enough, that also increased my docker image by 8GB. It seems texlive somehow still got installed in the container itself, just around 200MB are saved in the x86_64-linux. This is not really what was expected... but at it seems to work now. I also have the impression that previous caches steadily prevent recompilation of projects no matter if you try compile from scratch. the frog example I had from previous attempts in my library would steadily refuse to find the picture, but when recreating that example file via the interface it would work no problem. Cheers!

Resolved it by first duplicating the 2 affected shares then deleting the old ones and renaming the new ones to the previous names on unraid. That solved the lock sign on the shares in OSX. Then removed and then recreated the crashing nextcloud sync connection. not elegant... but did the job.

Hi, I am aware that Mac OS SMB issues are an ongoing topic and seem to come in multiple flavours... here comes my contribution .... Some context: My setup consists of the unraid server, 2 apple laptops and a windows PC. On the unraid server I have a few private shares. To access them I have one user set up I use for smb access on all mentioned client machines. In addition to this I also run nextcloud which uses these shares as external storage and I have clients set up on the windows pc and the main macbook to sync files. This has worked ok for a few days now. The issue: At some point I noticed on the mac, that the nextcloud client would crash after a few seconds. I could narrow down the cause of the crash to 2 folders which sync the contents of 2 shares by stopping all other synchronisation. When mounting then these 2 suspicious shares via finder on the desktop, I noticed the padlock signs, however upon inspecting the properties the permissions for the correct user are read and write. Trying to write to the top directory of the 2 affected shares does not work e.g. /share1/, but strangely enough, I can write into a subdirectory of the share e.g. /share1/somefolder. All other shares behave as usual, no problems. On the PC side, I have no problems whatsoever. On the second mac laptop I have the same troubles as on the primary mac, but this one never had the nextcloud sync installed. So the trouble seems to be located with the shares themselves. I had a glance through the diagnostics and did not see anything obvious in the syslog.txt file, however I am not an expert. I would appreciate a holler if someone has come across this kind of problem and could kindly point me in the right direction. best, Ph unton-diagnostics-20240322-1256.zip Edit: Actually, I can delete files from a finder window in the top level of the problematic share , but I cannot drag and drop a file into it. Freefilesync also moves data back and forth without a problem... but nextcloud crashes on every sync attempt.

Hi @binhex , I tried another browser .... it works there instantly. In the initial browser clearing cached images and files and did the trick there. I did not know that a vnc could not appear to work because of some cookie / cash issue. Will keep it in mind. Many thanks, ph

Hi, I just updated Krusader, unfortunately the update seems to have introduced some problems, see below logs. The app does not work any more, the WebUI shows another error. Help would be appreciated. I am running Unraid 6.12.4. text error warn system array login int2: panel items: TSC 2024-03-18 01:28:15,361 DEBG 'start' stderr output: tint2: Systray composited rendering on tint2: nb monitors 1, nb monitors used 1, nb desktops 4 tint2: panel 1 uses scale 1 2024-03-18 01:28:15,423 DEBG 'start' stderr output: tint2: Kernel uevent interface initialized... 2024-03-18 01:28:15,424 DEBG 'start' stderr output: tint2: systray window 8388621 2024-03-18 01:28:15,424 DEBG 'start' stderr output: tint2: systray started 2024-03-18 01:28:15,666 DEBG 'start' stderr output: MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER) 2024-03-18 01:28:15,667 DEBG 'start' stderr output: glx: failed to create drisw screen 2024-03-18 01:28:15,667 DEBG 'start' stderr output: failed to load driver: zink 2024-03-18 01:28:16,020 DEBG 'start' stderr output: error 3: BadWindow (invalid Window parameter) request 20 minor 0 serial 434 2024-03-18 01:28:16,024 DEBG 'start' stderr output: error 3: BadWindow (invalid Window parameter) request 15 minor 0 serial 435 error 3: BadWindow (invalid Window parameter) request 20 minor 0 serial 436 error 3: BadWindow (invalid Window parameter) request 15 minor 0 serial 437 error 3: BadWindow (invalid Window parameter) request 20 minor 0 serial 438 2024-03-18 01:28:16,029 DEBG 'start' stderr output: error 3: BadWindow (invalid Window parameter) request 15 minor 0 serial 439 2024-03-18 01:28:16,029 DEBG 'start' stderr output: error 3: BadWindow (invalid Window parameter) request 20 minor 0 serial 440 2024-03-18 01:28:16,030 DEBG 'start' stderr output: error 3: BadWindow (invalid Window parameter) request 15 minor 0 serial 441 2024-03-18 01:28:16,030 DEBG 'start' stderr output: error 3: BadWindow (invalid Window parameter) request 20 minor 0 serial 442 2024-03-18 01:28:16,031 DEBG 'start' stderr output: error 3: BadWindow (invalid Window parameter) request 15 minor 0 serial 443 2024-03-18 01:28:16,032 DEBG 'start' stderr output: error 3: BadWindow (invalid Window parameter) request 20 minor 0 serial 444 2024-03-18 01:28:16,032 DEBG 'start' stderr output: error 3: BadWindow (invalid Window parameter) request 15 minor 0 serial 445 2024-03-18 01:28:16,032 DEBG 'start' stderr output: error 3: BadWindow (invalid Window parameter) request 20 minor 0 serial 446 2024-03-18 01:28:16,032 DEBG 'start' stderr output: error 3: BadWindow (invalid Window parameter) request 15 minor 0 serial 447 2024-03-18 01:28:16,033 DEBG 'start' stderr output: error 3: BadWindow (invalid Window parameter) request 20 minor 0 serial 448 2024-03-18 01:28:16,033 DEBG 'start' stderr output: error 3: BadWindow (invalid Window parameter) request 15 minor 0 serial 449 2024-03-18 01:28:16,034 DEBG 'start' stderr output: error 3: BadWindow (invalid Window parameter) request 20 minor 0 serial 450 2024-03-18 01:28:16,034 DEBG 'start' stderr output: error 3: BadWindow (invalid Window parameter) request 15 minor 0 serial 451 2024-03-18 01:28:16,035 DEBG 'start' stderr output: error 3: BadWindow (invalid Window parameter) request 2 minor 0 serial 471 error 3: BadWindow (invalid Window parameter) request 20 minor 0 serial 472 2024-03-18 01:32:13,289 WARN received SIGTERM indicating exit request 2024-03-18 01:32:13,290 DEBG killing start (pid 70) with signal SIGTERM 2024-03-18 01:32:13,295 INFO waiting for start to die 2024-03-18 01:32:13,303 DEBG 'start' stderr output: Signal: 15 X connection to :0 broken (explicit kill or server shutdown). Signal: 15 In exit 2024-03-18 01:32:13,305 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 23117275914576 for <Subprocess at 23117276021584 with name start in state STOPPING> (stdout)> 2024-03-18 01:32:13,306 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 23117275846800 for <Subprocess at 23117276021584 with name start in state STOPPING> (stderr)> 2024-03-18 01:32:13,307 WARN stopped: start (exit status 143) 2024-03-18 01:32:13,310 DEBG received SIGCHLD indicating a child quit ** Press ANY KEY to close this window ** Best, ph

ich habs dann einfach noch einmal ausprobiert - ich kann bestaetigen, dass auch beim WU2 der betrieb headless (mit iGPU) ohne einen dummy plug moeglich ist. (es hatten sich da wie so oft einige probleme ueberlagert, deswegen die urspruengliche frage) lg

ok, danke dir - das ist ja schon einmal ein anhaltspunkt.

Hallo zusammen, nur eine kurze frage an nutzer/ kenner dieses mainboards - gehe ich recht in der annahme, dass man den dummy plug fuer den headless betrieb bei dem board braucht ? ich benutze es mit einer igpu (i3 8100). ich habe zu dem thema nichts in der anleitung gefunden aber in anderen foren wurde generell erwaehnt, dass das bei manchen boards bei headless betrieb mit einer igpu von noeten ist. danke im voraus, Lg ph_

Update: I tried the Safe Mode with GUI. My settings: Spindown after 15 mins, Array is stopped as for one missing parity. Result: Disks stay spinning for 30mins, then at 31mins start spinning down, at 32 mins start spinning up again. Conclusion: Safe Mode does not make any difference. As for my goal to add a new drive to the array and reactivate it - seems I have to endure having that array spin up and down every few mins while it takes 2 days to pre-clear my 10TB ironwolf disk. Any other suggestions ? If I decide to downgrade to 6.10 again - that probably would mean that my dockers stop working (as they have been upgraded in the meantime) or introduce other new problems ? Possibly any changes to this strange behaviour in even newer versions of Unraid ?

Hi Simon, thx for the reply - alright, guess gonna give that safe mode a shot. While it might keep checking if disks are still there, why would it spin them up though, if the user has disabled the array ? If this is a design decision... it is a rather poor one. Cheers 🙂

Hi, as the headline says... I am certainly not the first person to have this problem, but I also could not find a conclusive solution to the issue. I am not keen on downgrading, as this will probably create new issues with docker images I have upgraded since switching from 6.10.0 to this newer version. So, array has been stopped, because I took out one of the parities. Hence there should be no reason whatsoever to spin up disks. I guess the problem was there before I took one of the parities out, I guess was less obvious then that something is going awry. If someone could advise where to look in the diagonstics - I checked syslog and it does not say much more then what I already know: .... Feb 20 12:44:13 Unton emhttpd: read SMART /dev/sdb Feb 20 12:44:25 Unton emhttpd: read SMART /dev/sdc Feb 20 12:59:03 Unton emhttpd: spinning down /dev/sdb Feb 20 12:59:15 Unton emhttpd: spinning down /dev/sdc Feb 20 13:00:13 Unton emhttpd: read SMART /dev/sdb Feb 20 13:00:25 Unton emhttpd: read SMART /dev/sdc .... What else can I check ? best! unton-diagnostics-20240220-1630.zip

hey, sorry, I have not dealt with this for a while now. So, no I have not fixed it yet. Any enlightenment in the meantime ? Cheers

Replying to my own post, there is some info on the german corner of the forum: I guess you easily get obsessed with saving power if you have electricity prices as skyhigh as in germany....

Hi, I have read here and there that certain NVME drives might be responsible for Systems not being able to reach lower power states such as C7 or C8. If this is the case, is there some guidance which models are proven good in that respect and which ones are troublesome and thus better to be avoided for low power server builds? In particular, I was interested in experience with Enterprise NVME drives as many of those have capacitors onboard preventing data loss in a case of sudden power failure which seems like a great feature to have (although maybe not necessary if you have a UPS?) . Point being that those types of drives are apparently especially uncooperative when it comes to low power management. I would appreciate some insight being shared or links with more information. Many thanks!