Leaderboard

I posted this on the serverbuilds.net forums, and noticed that several users here were interested, so cross-posting! This a somewhat complex yet in-demand installation, so I figured I'd share my steps in getting a Riot.im chat server syndicated through a Matrix bridge that supports a Jitsi voip/video conference bridge. The end result is a self-hosted discord-like chat server where any chat room can become a video conference with a single click! It has some other neat features like end-to-end encryption and syndication with other matrix server AND other types of chat servers (you can have a chat room that links to a discord room, irc channel, etc). We'll do almost all of this using apps from the Unraid Community Applications repo! Summary: We'll setup some domains for each of our components, then use a LetsEncrypt proxy to generate certificates. Matrix will run the back-end, Riot Chat will run the front-end, and Jitsi will handle the A/V. DNS Setup: You're gonna want a few subdomains, even if you have a dyndns setup pointing to your host. Then can all point to the same IP, or you can use CNAME or ALIAS records to point to the root domain. A DNS setup for somedomain.gg might look like this: Type - Host - Value A - @ - 1.2.3.4 (Your WAN IP) CNAME - bridge - somedomain.gg CNAME - chat - somedomain.gg CNAME - meet - somedomain.gg In the above-the `@` A-record will set the IP for your domain root, and the CNAME-records will cause the 3 subdomains to resolved to whatever domain name you point them at (the root domain, this this case). Each domain will host the following: bridge: matrix - The core communications protocol chat: riot - The chat web UI meet: jitsi - The video conferencing bridge Firewall Setup: You'll need the following ports forwarded from you WAN to you Unraid server: LetsEncrypt: WAN TCP 80 -> LAN 180 , WAN TCP 443 -> LAN 1443, WAN TCP 8448 -> LAN 1443, all on your Unraid server IP - 80: Used by LetsEncrypt to validate your certificate signing request -- this can be disabled after setup, then only enabled when you need to renew a certificate. - 443: LetsEncrypt proxy for encrypted web, duh - 8448: Matrix Integrations port for enabling plugins. Also proxied via LetsEncrypt. Make sure this points to 1443, not 8443! STUN: TCP and UDP 3478 on WAN -> 3478 on Unraid (or changed to suit your needs) Jitsi: UDP Port 10000 -> 10000 on Unraid We'll be assuming you used these ports in the rest of the guide, so if you needed to change any, compensate as needed! Docker Networking: This is a fairly complex configuration that will use at least 7 docker containers. To make this easier we'll create a custom docker network that these containers will all live on, so that they can communicate between each other without having to worry about exposing unnecessary ports to your LAN: 1. In Unraid, go to Settings->Docker. 2. Disable docker so you can make changes: set `Enable Docker` to `No` 3. Set `Preserve user defined networks` to `Yes` 4. Re-enable Docker 5. Open the Unraid console or SSH in. 6. Create a new Docker network by executing `docker network --subnet 172.20.0.0/24 create sslproxy` or whatever subnet works for you (adjusted below as needed). We're now done with the pre-install stuff! I'd suggest testing your DNS and that the ports are all open on your FW and are getting directed to the right places. If everything looks good, then lets get some dockers! LetsEncrypt Install: Before proceeding, wait for your DNS server to update and make sure you can resolve the 3 subdomains remotely. This is REQUIRED for LetsEncrypt to validate the domains! LetsEncrypt will need listen on port 80 and port 443 of your WAN (public-facing) interface so that it can validate your ownership of the domains. We're going to use a Docker from the Unraid Community Applications docker. But before we do, we need to enabled user defined networks in our Docker settings. But first, 1. In Community Applications, search for `LetsEncrypt` and install the container from `linuxserver` 2. Set the `Network Type` to `Custom: ssl proxy` 3. Set the `Fixed IP address` to `172.20.0.10` (or whatever works for you) 4. Make sure `Privileged` is set to `On` 5. Set the `http` port to `180` and the `https` port to `1443` 6. Supply an email 7. Enter your domain name, ie `somedomain.gg` 8. Enter your subdomains: `chat,bridge,meet` (and any others you want to encrypt) 9. Optional: set `Only Subdomains` to false if you want the root domain to also have a cert! The rest of the options should be fine as-is. If you do NOT have a domain, but use a dynamic dns service, you can still mange but might be limited to a single domain. Make sure `Only Subdomains` is set to `True`, otherwise your install will fail as LetsEncrypt will expect you have be running on your dyndns services web server! The following steps will also require you to do some nginx subdirectory redirection instead of domain proxying. SpaceInvader has a great video that demonstrates this in detail. Once you've created the docker instance, review the log. It might take a minute or two to generate the certificates. Let it finished and make sure there are no errors. It should say `Server ready` at the end if all goes well! Try browsing to your newly encrypted page via https://somedomain.gg (your domain) and make sure all looks right. You should see a letsencrypt landing page for now. If all went well, your LetsEncrypt certificates and proxy configuration files should be available in /mnt/user/appdata/letsencrypt/ LetsEncrypt Proxy Configuration: LetsEncrypt listens on ports 80 and 443, but we also need it to listen on port 8448 in order for Riot integrations via the public integration server to work property. Integrations let your hosted chatrooms include bots, helper commands (!gif etc), and linking to other chat services (irc, discord, etc). This is optional! If you're happy with vanilla Riot, you can skip this. Also, you can run your own private Integrations server, but I'm not getting into that here. So assuming you want to use the provided integrations, we need to get nginx listening on port 8448. To do that, edit `/mnt/user/appdata/letsencrypt/nginx/site-confs/default` and make the following change: Original: New: Next, we are going to need 3 proxy configurations inside LetsEncrypt's nginx server (one for matrix, riot and jitsi). These live in `/mnt/user/appdata/letsencrypt/mnt/user/appdata/letsencrypt/`. Create the following file: matrix.subdomain.conf: riot-web.subdomain.conf: jitsi.subdomain.conf: ^^^ NOTE!!! Make sure you saw the `CHANGE THIS` part of the `$upstream_app` setting. This should be the LAN IP of your Unraid server! Done! To test, trying visiting https://<subdomain>.somedomain.gg/ and you should bet a generic gateway error message. This means that the proxy files attempted to route you to their target services, which don't yet exist. If you got the standard LetsEncrypt landing page, then something is wrong! Matrix A Matrix container is available from avhost in Community Applications. 1. In Community Applications, search for `Matrix` and install the container from `avhost` 2. Set the `Network Type` to `Custom: ssl proxy` 3. Set the `Fixed IP address` to `172.20.0.30` or whatever works for you 4. Set the `Server Name` to `bridge.somedomain.gg` (your domain) 5. The rest of the settings should be fine, and I suggest not changing the ports if you can get away with it. Create the container and run it. Now we need to edit our Matrix config. 1. Edit `/mnt/user/appdata/matrix/homeserver.yaml` 2. Change `server_name: "bridge.somedomain.gg"` 3. Change `public_baseurl: https://bridge.somedomain.gg/"` 4. Under `listeners:` and `- port: 8008` change `bind_address: ['0.0.0.0']` 5. Change `enable_registration: true` 6. Change `registration_shared_secret: xxxx` to some random value. It doesn't matter what it is, just don't use the one from the default config! 7. Change `turn_uris` to point to your domain, ie `"turn:bridge.somedomain.gg:3478?transport=udp"` 8. Set a good long random value for `turn_shared_secret` If you have errors at start-up about your turnserver.pid file or database, you can try editing your /mnt/user/appdata/matrix/turnserver.conf file and adding: pidfile=/data/turnserver.pid userdb=/data/turnserver.db There are a ton of other settings you can play with, but I'd wait until after it working to get too fancy! Now restart the Matrix container, and check that https://bridge.somedomain.gg/ now shows the Matrix landing page. If not, something's wrong! Riot Chat Riot Chat servers as we web front-end chat interface. There's also a great mobile app called RiotIM. For the web interface, there's an Community Applications image for that! 1. Before we start, we need to manually create the config path and pull in the default config. So open a console/SSH to your server. 2. Create the config path by executing `mkdir -p /mnt/user/appdata/riot-web/config` 3. Download the default config by executing `wget -O /mnt/user/appdata/riot-web/config/config.json https://raw.githubusercontent.com/vector-im/riot-web/develop/config.sample.json` (**NOTE**: This is a different URL than the one suggested in the Docker!) 4. In Community Applications, search for `riot web` and install the container from `vectorim`. Watch you, there are two -- use the one with the fancy icon, which doesn't end with an asterisk (`*`)! 5. Set the `Network Type` to `Custom: ssl proxy` 6. Set the `Fixed IP address` to `172.20.0.20` (or whatever) 7. The rest of the settings should be fine. Create the container and run it. Now lets edit our Riot config. It's a JSON file, so make sure you respect JSON syntax 1. Edit ` /mnt/user/appdata/riot-web/config/config.json` 2. Change `"base_url": "https://bridge.somedomain.gg",` 3. Change `"server_name": "somedomain.gg",` 4. Under the `"Jitsi:"` subsection near the bottom, change `"preferredDomain": "meet.somedomain.gg"` If all went well, you should see the Riot interface at http://chat.somedomain.gg! If not, figure out why... Now lets create our first account! 1. From the welcome page, click `Create Account` 2. If the prior config was correct, `Advanced` should already be selected and it should say something like `Create your Matrix account on somedomain.gg`. If the `Free` option is set, then your RiotChat web client is using the public matrix.org service instead of your private instance! Make sure your `base_url` setting in your config.json is correct. Or just click Advanced, and enter `https://bridge.somedomain.gg` in the `Other Servers: Enter your custom homeserver URL` box. 3. Set your username and password 4. Setup encryption by following the prompts (or skip if you don't care). This may require that you whitelist any browser script blockers that you have running. Done! You now have a privately hosted Discord-alternative! Lets add some voice and video chat so we can stop using Zoom 😛 Jitsi This part doesn't have a solid Docker image in the Community Application store, so there's a few more steps involved. We're gonna need to clone their docker setup, which uses docker-compose. 1. Open a console/SSH to your server 2. Install docker-compose by executing `curl -L "https://github.com/docker/compose/releases/download/1.25.5/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose` 3. Make it executable: `chmod u+x /usr/local/bin/docker-compose` 4. Move to your appdata folder : `cd /mnt/user/appdata` 5. Make and enter a folder for you docker-compose projctes: `mkdir docker-compose; cd docker-compose` 6. Clone and enter the `docker-jitsi-meet` repo: `git clone https://github.com/jitsi/docker-jitsi-meet ; cd docker-jitsi-meet` 7. Create an install environment: `cp env.example .env` 8. Populate some random secrets in your environment: `./gen-passwords.sh` 9. Edit the install environment (I'm using nano, but edit however you want): nano .env 10. Change `CONFIG=/mnt//mnt/user/appdata/jitsi-meet/` 11. Set TZ to your timezome, ie `TZ=America/Denver` 12. Change `PUBLIC_URL=https://meet.somedomain.gg` 13. Change `DOCKER_HOST_ADDRESS=192.168.0.1` or whatever the LAN address of your Unraid server is 14. Create the CONFIG path that you defined in step 10: `mkdir /mnt//mnt/user/appdata/jitsi-meet/` 15. Create and start the containers: `docker-compose -p jitsi-meet -f docker-compose.yml -f etherpad.yml up -d` 16. This will create 4 Jitsi containers are part of a Docker Stack -- see your list of dockers. You can't edit them, but take note of the `jitsi-meet_web_1` ports, which should be `8000` and `8443`. If you got any errors, it's likely a port conflict somewhere, so find the corresponding setting in your `.env` file and adjust as needed, reflecting any relevant changes in the next step. When we were setting up our Nginx proxy configs, you'll recall that the Jitsi config `$upstream_app` had to be set manually, rather than relying on the internal DNS. That's because the docker-compose stack names are not 100% predicatble, so it's better to just hard-code it. You might want to double-check that setting if you have in uses from here on. To test Jitsi, go to https://meet.somedomain.gg/ and hopfully you see the Jitsi page. Try to create a meeting. In the future, it may be wise to enable Authentication on your Jitsi server if you dont want any random person to be able to host conferences on your sever! See the docs (or SpaceInvader's video) for details on that. Now find a friend and get them to register a Riot account on your server at https://chat.somedomain.gg (or use the mobile app and connect to the custom host). Get in a chat room together, then click the Video icon next to the text input box and make sure it works. It's worth noting that Jitsi works differently when there are only 2 people chatting -- they'll communicate directly. With 3 or more, they'll communicate with the Jitsi server and use the TURN service. So it's a good idea to try to get a 3rd person to join as well, just to test out everything. Thats it, hope this helps! Enjoy! To Do: * Custom Integrations Server * Etherpad Integration Edit: While I was making this guide, SpaceInvader came out with a great video covering the Jitsi part! It covers some authentication options that I didn't get into, but would highly suggest. Check it out!

Hi, The issue: At the moment, there is two way to use a 3D application in a VM with unRAID. First way is to passtrough a GPU to it. While this solution is nice and work well if you have only 1 or 2 VM's that need GPU acceleration, it's not ideal when you need multiples accelerated VM's. The second way is to use the intel GVT capabilities, however, the UPT is not super well implemented yet and the graphical power of those IGD are not that great. The solution: It would be nice if you could include GPU virtualisation (vGPU) solution, there is more than one solution to achieve this, but I think virtio-gpu and virGL is our best shoot. There is also MxGPU with the AMD GIM driver or Nvidia GRID but it require expensive gpu card to work. If virtio-gpu is implemented, it would be nice to see spice implemented as well since its more efficient than a VNC. Also I might dreaming here, but if there was a way to use one GPU to display more than one VM desktop. Example, if there 3 hdmi output on the card, display the desktop on the VM 1 on the HDM1 and the VM 2 on the HDMI2 and so on. Some interestings links : https://www.spice-space.org/spice-user-manual.html https://www.kraxel.org/blog/2016/09/using-virtio-gpu-with-libvirt-and-spice/ https://www.kraxel.org/slides/qemu-gfx-2016/ Regards, Mathieu

SO i got the system up and running here is what i did Pulled the flash drive, backing up the drive on my laptop wiped and reran the OS with 6.8.2 vs 6.8.3 it was on before. Also moved the flash drive to a USB 2.0 port (new motherboard so i didnt realize i had placed it on a 3.0 port Booted up perfectly. I think that the issue is related to either the OS itseld as I did try to do a rebuild before and it was a hit or miss every reboot, or it was the usb 2.0 which very well could be as it is always wise to run it on a stable legacy port.

Ahh... I somehow missed your post about the floppy! I read it and also found the following which was the key. I followed the instructions and blam! Thank you so much for your suggestion. It was key.

6.9, apparently.

Ok, so I'm on day 3 of zero crashes. Looks like my issue has been fixed. Summary below of the changes that appear to have led me to this stable result. - Moved Unraid USB to 2.0 slot. - Flashed BIOS to latest version (1.30) - Disabled all power management features - No overclocking at all (Everything default or Auto) - Changed BIOS setting "Power Supply Idle Control" to "Typical Current Idle" - Uninstalled GPU Statistics plugin - Added "rcu_nocbs=0-31" to the kernel - Disabled Bonding and Bridging in Network Settings - Changed BIOS setting "Global C State" to "Disabled"

I have to go now, someone else should be able to help you if still needed, but I'll check back tomorrow.

Yea i think that your issue. I will building a real ryzen hackintosh in the next week with a 3600 for a friend and looking at your config.plist i see why it was so different from ours. What GPU are you using?

a second server is def doable with caveats, more on that in a min, this is the procedure for setting up a second server:- 1. go to unraid web ui/docker and 'add container' 2. from the 'template' dropdown select under the heading '[user templates]' your existing minecraftbedrock server container 3. change the 'name' of the container from 'binhex-minecraftbedrockserver' to something else. 4. change the host ports to a different number, so change all references to 19132 to say 18132 and all ref to 19133 to 18133 5. then click on 'show more settings' and change the host path for /config to something else, for e.g. just put a '2' on the end of the path click on apply. 6. this will now start a new container running minecraft on a different port with a different path to store configuration now comes the caveat:- so because you cant use the same port as the first server you can only use this with minecraft bedrock clients that allow you to specify the port number, e.g. Minecraft PE clients i think allow this, for things like xbox one i am not sure this is possible.

i have used them, yes they work. I went back to just spoofing Ivy bridge because GPU performance is just better that way,

Also note that caching user share writes doesn't happen unless you make it happen. Each user share has settings including whether and how it uses cache. In addition to domains share being on cache, your appdata and system shares will be (and should be) on cache by default.

CRC errors are a connection problem, also a single error is nothing to worry about, just acknowledge it on the dashboard, if it keeps increasing re-seat the device.

Reboot your system and see if the interface is no longer created.

Q1) Using Only is fine as long as you do not already have files in that share on the array. If you DO have files on the array then set it to Prefer; disable the VM service and Docker services under Settings; run mover to get the files moved to the cache; re-enable the Docker and VM services; (optional) change the Use Cache setting to Only. Q2) There is no way to explicitly set the division between VM and file caching. What you can set is the Minimum Free Space setting under Settings >> Global Share settings and when free space on the cache falls below this then files get written directly to the array. The recommended value is to be larger than the size of the largest file you are likely to write. Having said that since you do not have a parity drive (which is what limits speed writing to array drives) I wonder if you even need to bother caching file writes in the first place.

Did you set the UMask as explained in the first post of this thread?

Check out the preset heimdall subdolder proxy conf. It does exactly that

Got it working, after hours of port forwarding problems but now were good Thanks for all your help!

Feature Requests: 1.) Jump to top if "Edit Script" is selected or display the code under the scripts row (maybe better as it prevents scrolling) 2.) *deleted* 3.) "Show log" uses the -0700 timezone. Instead it should respect the Unraid timezone setting 4.) Changing a script name should rename the script filename, too. Or the User Scripts overview should be sorted by the script name and not the script filename. 5.) Maybe its nice to see directly if a script returned an error. Maybe by displaying the row with a red background color?! 6.) Optional: Send script output to email address. 7.) If you add a cogwheel symbol after the script name you do not need to explain the user how to edit a script ("For more editing options, click on any script's name"), but I'm not sure if this would look good 8.) "Add new script" should contain the code textarea as well (no need for the extra step to edit it) Thank you for reading and building this plugin!

Hey! Just installed Catalina. Would have been a very smooth process but I had to trouble shoot for a long time before I finally realized my Chrome add-ons prevented me from connecting with VNC. However, now that I'm inside my Catalina VM I can't seem to change my keyboard layout. Since I am from Sweden it is quite different. I tried changing it both in the Mac-settings as well as inside the VM-template with no result. What can I do? Edit: Solved this by copying xml, changing to Swedish in the template, saved, compared the changed xml and found the value I needed to change to 'sv'. Pasted the original xml back and only did that small change Value is called keymap

The ‘Previous’ folder on the flash drive will hold the files associated with the last release. Copying these files back to the root of the flash drive and rebooting will restore that release. Before you do this you might want to get the system diagnostics zip file for the 6.8.3 release by running the ‘diagnostics’ command which will put the resulting file into The ‘logs’’ folder on the flash drive, and then post that file here. I do not believe there is any known issue with Intel NICs in the 6.8.3 release, so it is quite possible that something else is going on rather than your NIC simply not being detected and the contents of the diagnostics zip file might allow us to determine what that might be.

funnily enough i noticed the .debug file yesterday, a quick investigation and found out that its included in the minecraft release from mojang, i can only assume this is a way of running the server in a debug mode, obviously its pretty big so we dont want it copying across to /config, i have now added to the exclude list so it wont rsync across, image is now building with this change. note - the file will NOT be deleted, but you are safe to delete it once this change is in.

The new 5.6 kernel nvidia drivers JUST got posted on slackbuilds. So it wasn't even possible before

Has anyone using a ConnectX-3 card had any luck tuning their NFS/SMB settings to allow for increased throughput? I'm testing between two ramdisks on two unraid servers and only getting a max of 1.5GB/s while I get 39.5Gbps using iperf3.

This is addressed in version 6.8. Passphrases are no longer stored in a keyfile.

Absolutely not. Here's how it works. There are two ways to specify an encryption key: Using a passphrase. In this case what you type is exactly what will be used for the key, without any newline at the end (because did you type a newline? No). The max length for a passphrase is 512 bytes (characters). As specified in the Help, "It is highly advisable to only use the 95 printable characters from the first 128 characters of the ASCII table." A passphrase is meant to be some kind of string that you commit to memory and type in following server reboot. Use a keyfile. Whatever contents are in this file are what is used for the key. The max length used from a keyfile is 8192 bytes. Since contents are in a file, each byte can take on any value. Often one would use a file with random binary data. If the specified file is greater than 8192 in length, only the first 8192 bytes comprise the key. If you use a passphrase, whatever you typed is not stored in a file, though it is kept in memory. If you use a keyfile, then file uploaded data is written to /root/keyfile and it stays there for as long as sever has power. There is a button in webGUI that lets you delete the file if you want. But then each time you Start array you will have to upload file again, and then presumably delete again. Using a keyfile lets you specify a far stronger key, but onus is on you to delete the file.

Try changing the virtualized NIC model. Does the device manager in XP show a driver issue on the NIC? <model type='e1000' /> <model type='rtl8139' /> <model type='virtio' /> https://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/sect-Virtualization-Troubleshooting-KVM_networking_performance.html

Aside from you actually being correct, for many reasons, this keyfile is created so that you don't have to type your password in for every single LUKS disk in your array. Ideally, a few things should change with this part of the system. Allow me to point out an assumed security that is incorrect from people in the thread thus far: "It's in /root, so it's only available to the root user" - this is wrong for a couple of reasons; for one, this relies on no docker's being configured in such a way that they cannot see "/root" as any docker that uses a root account would also have access to this file. Furthermore, any bootable distribution, or hypervisor would also have access to this file (though it is detroyed every shutdown) Furthermore, the file is both plaintext, and stored in memory. Anything that manages to gain access to memory (We have several major vulnerabilities right now that affect different hardware and software implementations that allow access to the memory map, even to protected regions) can see this password. All of this assumes that simple privilege escalation attacks aren't viable (which they have been, in recent times, even.) In 2019, the only time a key should be plaintext is at the moment it is used. After that the variable it is contained in should be overwritten and destroyed. We must overwrite it because the kernel will simply mark that region "free" rather than writing 0's to it. Sure, it takes microseconds for it to be overwritten after being marked free on a system that has high memory utilization, but that's time it's available. We want to destroy the variable so there is no reference to it to make it identifiable after we use it. Furthermore, while it *is* convenient to have a single password for all of the disks - this is not ideal. Ideally (Imho) Unraid should generate a salted and hashed key from the user-defined luks password for each drive. You have two sources of unique data for each disk: The unraid license key, and the disk serial number. Using the license key ensures that no two unraid users can end up with the same salted key - even if they choose the same password and somehow have two disks with the same serial number. These salted keys should be generated based on the user's input and each disk should have its own unique key to mount it. This greatly increases the security of the system against brute force attacks.

My question still stands: WHY IS UNRAID STORING MY SECRET PASSWORD IN PLAIN TEXT? If I am not using a keyfile, then why do I have to delete a keyfile every time I start the array? So now I not only have to enter the password, I have to remember to delete the keyfile as well even though I don't use one? And I should add that it needs to be securely deleted by overwriting with random/cryptographic data to prevent data leakage. And how many other Unraid users have their key exposed and don't know about it because they never poked around? LUKS is very secure, but Unraid effectively makes it completely insecure by publishing the password. In fact, I dare to say it's even worse than no security because it gives users a false sense of security, thinking their data is protected and lets them relax on other security measures when in fact their password is actually published in clear text. It's not a hash. It's not salted. It's the password stored in a plain text file with the blatant name "/root/keyfile". It's the equivalent of a password written on a Post-It note and stuck on your monitor. How is this not a big deal to people? This is a HUGE security flaw that basically negates LUKS entirely.

I would like make the "unRAID OS GUI Mode" the default boot option. IE: No Prompt, default. I'm a little unsure how to do it and fear I'll make my system unbootable if I screw up. So do I simply modify syslinux.cfg? Current syslinux.cfg default /syslinux/menu.c32 menu title Lime Technology, Inc. prompt 0 timeout 50 label unRAID OS menu default kernel /bzimage append pci-stub.ids=8086:105e initrd=/bzroot label unRAID OS GUI Mode kernel /bzimage append pci-stub.ids=8086:105e initrd=/bzroot,/bzroot-gui label unRAID OS Safe Mode (no plugins, no GUI) kernel /bzimage append initrd=/bzroot unraidsafemode label Memtest86+ kernel /memtest Is this correct? Would I simply move the line "menu default" from "label unRAID OS" to "label unRAID OS GUI Mode" like below??? default /syslinux/menu.c32 menu title Lime Technology, Inc. prompt 0 timeout 50 label unRAID OS kernel /bzimage append pci-stub.ids=8086:105e initrd=/bzroot label unRAID OS GUI Mode menu default kernel /bzimage append pci-stub.ids=8086:105e initrd=/bzroot,/bzroot-gui label unRAID OS Safe Mode (no plugins, no GUI) kernel /bzimage append initrd=/bzroot unraidsafemode label Memtest86+ kernel /memtest Thanks in advance

I thought this might be a good FAQ entry, so created it: What is "Boot GUI mode", and how do I change to it? Feel free to edit it, or suggest changes.

What is "Boot GUI mode", and how do I change to it? Some users run unRAID as headless, and if you do, then this FAQ is not for you. The Boot GUI is a GUI replacement for the text based terminal screen on the server console that we have always seen after boot, until now. It provides the same unRAID screens on the server monitor that you normally get when you open your unRAID server from a browser on another desktop. One important requirement - a mouse! If you have never viewed a GUI on your server machine, then you may not have one attached, and any GUI requires a mouse. Because support is built in, getting a mouse working should be easy, but may not be (and you may have to reboot). To set the GUI mode, go to the Main screen and click on your unRAID flash disk (on the word 'Flash'), to open its settings page. Go down to the Syslinux Configuration section. This is a viewer and editor of your syslinux.cfg file, the file that controls the boot menu for your server. After some preliminary general settings lines, you will see a series of sections that begin with label. Each section controls a separate menu line on your boot menu. In one of them is the line "menu default", which marks the menu item that will be performed if nothing is selected within the allotted time. To change the default menu selection, simply move the "menu default" line into the section you want to be the default, then click Apply then Done. Try it and see, you can always change it back. One warning! This uses Firefox as the browser to open the unRAID server management pages. It's fine for that, but because it's a browser, it will be tempting to go on the Internet. It is NOT configured to securely access the Internet! Don't do it! To be safe, use it only for managing your unRAID server. (This author is not sure of the security implications and dangers here, and prefers to err on the side of safety.) An example of a modified syslinux.cfg - default /syslinux/menu.c32 menu title Lime Technology, Inc. prompt 0 timeout 50 label unRAID OS kernel /bzimage append initrd=/bzroot vga=6 label unRAID OS GUI Mode menu default kernel /bzimage append initrd=/bzroot,/bzroot-gui vga=6 label unRAID OS Safe Mode (no plugins, no GUI) kernel /bzimage append initrd=/bzroot unraidsafemode vga=6 label Memtest86+ kernel /memtest