SpaceInvaderOne

I find the easiest way to move to a larger disk is not expanding the existing disk but to migrate to a new disk instead. 1. Create new macOS vm with larger disk. (ie 200G) 2. Stop new VM 3. Add the old macOS vm's vdisk (100g disk) as an additional disk to the new vm in its template. 4. Boot into new vm 5. Run migration assistant (applications/utilities/migration assistant) 6. Now you can migrate all programmes data and settings from the old vdisk to the new larger vdisk 7. After migration complete shutdown vm. 8 Remove old vdisk from template 9. delete old vdisk or keep as backup.

Hi, I think it would be really great to be able to set individual mover schedules that are specific to each cache pool. As i would find it useful to have some pools move files more often than others.

Ah i was writing the reply when you posted this. Glad its working for you

Ah its an easy mistake to make , I have done the same before myself many times before You can change the grafana port or the rocket chat port. If you change the rocket chat port you will have to make a change in reverse proxy config file too as the confile file expects the port that Rocket chat is using to be 3000. So its this bit here you would need to change. server { listen 443 ssl; server_name rocketchat.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { resolver 127.0.0.11 valid=30s; set $upstream_app Rocket.Chat; set $upstream_port 3000; <<<<<<<<<<<<<<<<<<<<<<<<you would have to change the port here to match whats specified in the template>>>>>>> set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto http; proxy_set_header X-Nginx-Proxy true; proxy_redirect off; } } server { listen 80; server_name rocket.*; return 301 https://$host$request_uri; }

So you get an error like this when you click on start for the container? Most likely you have another container running with the same port in use. Is anything else using port 3000? Grafana also uses port 3000 by default.

Here is a guide showing how to setup Rocket chat running through a reverse proxy. Also you can update the container but when you setup the mongoDB you must specify the hostname in the container when you create it. That way when the container is ever recreated it keeps the same name and so doesnt cause the database to break. If you already have rocket chat installed and have disabled updates then see a fix that will allow you to update as normal at the end of my video.

Heres a video showing how to setup Rocket chat . Three conatiners are needed a mongoDB, linuxserver's letsencrypt reverse proxy and of course the Rocket Chat container. Hope you find this useful

I just updated to the the nextcloud container to latest. After which i couldnt access nextcloud and was getting 400 bad request error So if anyone else has this error you can fix by rolling the container back To do that change the repository line in the template to linuxserver/nextcloud:18.0.4-ls81 as below

@tomwhi @jazzyjeff yeah I should have added more variables for sure. Extra variables have been added to the template now. All can be left as default settings and should work. Personally I think using a custom ip is better than running as host (just so you dont have to change the web port and can access the container just by ip in a browser.) but if you run as host network then you will need to change the listing port. VNC now enabled by default to view Zigbee mesh. Add vnc password if you wish. To see debug and upnp options these are hidden by default so click show more settings at the bottom of the template.

@kskoba your welcome

Have you updated the motherboard bios then since doing this the vm no longer works? This was a problem with ryzen cpus when the 3000 series came out and people updated their bios when their cpu was not a 3000 series. Then black screen on gpu. I made a video about it here https://www.youtube.com/watch?v=l-WHCCwgyDg&feature=emb_logo If that was the case you can try to downgrade the bios using this video here https://www.youtube.com/watch?v=ZzqwjVDKAnU

A container for explain shell to run on your server (as a self hosted alternative to using the explainshell website.) What is it? Not everyone, especially people new to Linux and Unraid, know what a command that they type will actually do. Especially when reading online commands to type into their servers. So just paste the command into the search box and click explain and explainshell will breakdown the command explaining what each part does. Quite a useful tool.

There will be a video series (soon) for setting up Home assistant in docker (rather than hassio vm) along with deconz, mosquitto etc

This container needs a ConbeeII usb zigbee stick to work This container is for the deCONZ software from Dresden Elektronik. It is used to control a conbee zigbee usb stick and can be used with home assistant. Setup. 1. Without conbee usb stick plugged into the server run the following command in a terminal window ls /dev/ 2. Plug your conbee usb stick into the unraid server. Then run the above again. You will now see an extra device here. This is your conbee zigbee stick. Most likely ttyACM0 (unless you have maybe a zwave stick plugged in aswell then it might not be) 3. Now add the name of the stick to the template. (default is already ttyACM0) Add it to both usb conbee: and usb device name: 4. I think it best to set a static ip for the container. You can then access the container from http://xxx.xxx.xxx.xxx (the ip you set) 5. Now you can add your zigbee devices in the webui and connect deconz to home assistant for it to be able to access you zigbee devices.

A video guide on how to passthrough PCIe devices using the vfio-pci config plugin. Makes it super easy for passing through usb controllers and knowing which ones are safe to passthrough.