Leaderboard

Popular Content

Showing content with the highest reputation on 04/26/20 in Posts

  1. Just a simple little plugin to act as a front end for any little scripts that you may have that you may need to run every once in a while, and don't feel like dropping down to the command line to do it. (Or anything that I happen to run across here on the forum that will be of use to some people) Install it via Community Applications Only a couple included scripts: - Delete .DS_Store files from the array - Delete any dangling images from the docker.img file - Display the size of the docker container's log files (to see if a docker app is filling up the image file through excessive logging) Additional Scripts from myself (and hopefully other users) can be found here: To add your own scripts: Within the flash drive folder config/plugins/user.scripts/scripts create a new folder (each script is going to have its own folder) - The name doesn't matter but it can only contain the following characters: letters ([A-Za-z]), digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), periods ("."), and spaces (" ") Or, you can hit the button that says "Add Script", then give the script a name. Hovering over the script's name will then give you additional options. Including online editing... Create a file called description that contains the description of the script. Create a file called script this will be the actual script. Few notes: So as to make things easier for people: The script file can be created with any text editor you choose. DOS line endings will be automatically converted to Linux style endings prior to execution. #!bin/bash is automatically added to every script prior to execution to help out the noobies EDIT: This is only added if no interpreter is specified (ie: #!/bin/bash) If an interpreter is already specified (ie: #!/usr/bin/php), then line is not added Techie Notes: The scripts are actually copied and executed from /usr/local/emhttp/plugins/user.scripts/ /tmp/user.scripts/tmpScripts so if there are dependencies (other scripts, etc) stored in the same folder as the script file, you will need to specify the full path to them. Interactive (ie: answering yes/no to a question) scripts will not work.
    1 point
  2. 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!
    1 point
  3. Try changing /mnt/user/appdata/mfi in the template settings to instead be /mnt/cache/appdata/mfi (or if you don't have a cache drive, then /mnt/diskX/appdata/mfi'
    1 point
  4. Yes, you can do this. It's generally not recommended as your cache will run at the speed of the slowest drive. If this doesn't matter to you, go for it.
    1 point
  5. I think you mean on the dashboard. Known issue and fixed next release
    1 point
  6. No. Parity is realtime, when you format the disk, that is immediately applied to parity. If the data on the disk is irreplaceable from backup or reripping, then data recovery software may be able to help, but it's not simple to do.
    1 point
  7. Try this. Create a new file called strong-ssl.conf in the nginx folder and add this: https://github.com/gilbN/Nostromo/blob/master/Server/nginx/strong-ssl.conf Then where is says "include /config/nginx/ssl.conf;" Replace that line with include /config/nginx/strong-ssl.conf;
    1 point
  8. Look, I'm not trying to be rude and I don't claim to have all the answers. In fact, I asked you if you googled it because that's the first thing I do when I have an issue. I posted the picture of the first Google result (highlighted answer) because it tells you exactly what the issue is. I suggest you focus on that rather than get worked up about my post. It tells you "Error 522 indicates that Cloudflare is unable to reach the origin web server and the request times out", which means cloudflare can't connect to your server. I honestly don't know how to word it any clearer. It looks like you turned on caching on cloudflare (which we recommend against), and your server is not accessible. Check your ip, port forwarding, etc.
    1 point
  9. If nobody on this forum has anything, you might check the website for the application (see the github link in the first post). binhex and our other docker authors just provide the docker for the application, and support for setting up the docker. The applications themselves are written by others and typically have their own website where support is provided for actually using the application.
    1 point
  10. Thats's supported by UD, so it's fine.
    1 point
  11. Because They're now being removed from CA and a notice will go out via FCP
    1 point
  12. Likely won't make much (if any) difference but since surveillance drives are optimized for write intensive workloads I would probably use it as parity.
    1 point
  13. If you have done NO writes to the array since removing parity, then you can use Tools >> New Config with option to retain current assignments assign the parity drive; on the Main tab click the Parity is Valid checkbox and then start the array. This will start the array without writing anything to parity. You now stop the array; unassign the disk you are trying to recover; restart the array. If parity is valid you will now see the disk being emulated and its contents visible. If that is the case then you can stop the array; assign the disk to be rebuilt, s tart the array to rebuild the contents of the emulated disk to the physical drive. If the emulated drive after doing step 5 does not show your data that may mean parity is not valid. If the difference is minor then you may find the drive shows as unmountable and be able to run a file system repair on the emulated drive before attempting to rebuild it. It is worth emphasising that the rebuild only puts back what is shown on the emulated drive, so no point in attempting a rebuild if no data is showing at that point. In case it is not obvious the parity drive contains no actual data, and has no understanding of data. What it does contain is the information to restore the bit pattern on a missing drive using the combination of a particular sector on ALL the other data drives plus the parity drive.
    1 point
  14. Create a qcow2 image of 256 MB (from Unraid terminal): qemu-img create -f qcow2 /path/to/the/image/test.qcow2 256M This will create a qcow2 image of 256 MB. Enable NBD on the host and connect the qcow2 image as a network block device (from Unraid terminal): modprobe nbd max_part=8 qemu-nbd --connect=/dev/nbd0 /path/to/the/image/test.qcow2 Create EFI partition and format: Create GPT (from Unraid terminal): gdisk /dev/nbd0 w y Create EFI partition (from Unraid terminal): gdisk /dev/nbd0 n 1 <press Enter to accept default value> <press Enter to accept default value> EF00 w y Format the EFI partition as FAT32 (from Unraid terminal): mkfs.fat -F 32 /dev/nbd0p1 Create a folder for the mount point (advise is to create a folder in your shares, so you can write files into the EFI partition from your vm too): mkdir /path/to/the/mount/point/ Mount the EFI partition (from Unraid terminal): mount /dev/nbd0p1 /path/to/the/mount/point/ Copy your EFI files in /path/to/the/mount/point/ Unmount the EFI partition (from Unraid terminal): umount /path/to/the/mount/point/ Disconnect nbd0 (from Unraid terminal): qemu-nbd --disconnect /dev/nbd0 rmmod nbd (Optional) Rename the EFI partition from "NO NAME" to "EFI" From the virtual machine you can mount the new EFI partition and rename it with the command: sudo diskutil rename /dev/disk0s1 "EFI" where disk0s1 is the EFI partition. In the vm xml point to the qcow2 image and add <boot order='1'/>
    1 point
  15. Yeah I think you need to use the Code 43 workaround on Linux as well if you want to use Nvidia Drivers on non quadro cards.
    1 point
  16. For NVME drives that are in their own IOMMU group just add it to the vfio.pci list and check it as a pci devices in VM creation. NVME are really just pcie cards so no need to add them as a drive, Windows will see a pcie drive that it can install on.
    1 point
  17. No shame there, a life without silly gifs is a life I don't want to live! I just tried it out and it worked fine without any issues. The Firefox javascript console was a lot of help in getting it all sorted out. There might be some hints there.
    1 point
  18. okay so I changed NAT to forward WAN 8488 to LAN 1448 and I still fail the federation check. edit: Got it. miss type on your edit. its not "It SHOULD have said to forward WAN 8448 to LAN 1448" its: It SHOULD have said to forward WAN 8448 to LAN 1443 only pointing it out in case someone is right behind us trying to figure it out. I now pass the federation check. Thank you so much for the back and forth, defiantly could not have gotten this working with out you
    1 point
  19. Did you also add `listen 8448 ssl;` to your matrix.subdomain.conf nginx proxy? Edit: test it -- from an external network, brows to https://yourdomain:8448/ and see what you see. If you cant connect, your FW isn't setup or nginx isnt listening on the port. If you see the Nginx landing page, your port forward isn't setup. If you see a gateway error, your forward is setup incorrectly.
    1 point
  20. I didn't get the RiotBot message either, as I'm pretty sure that depends on Integrations working at the point (bots are integrations). To be clear,. have you opened the Integrations (tcp 8448 -> LetsEncrypt IP, and modify `letsencrypt/nginx/site-confs/default` to also handle port 8448 requests) port on your FW? If you have, check your browser's javascript console, which will likely show you where the failure is
    1 point
  21. I'm not sure. Do you get the Javascript 'Joining Room' with spiny wheel thing at all? When joining large rooms, it may take a minute for server-to-server syndication to complete, as your local Matrix servers pulls in all the user's, their stats, and the new room's chat history. The integrations may be related. It involves getting LetsEncrypt to also listen (ssl) on 8448, and proxying that into matrix. I didn't test this until AFTER I made that change, but it works for me. See the updates I made in the original post and give it a shot!
    1 point
  22. If both need to be publicly exposed, then this is 100% correct and you should try changing the STUN ports in the Matrix docker config and configuring the Jitsi TURN service to redirect to the corresponding port. Most users probably don't want to expose the UniFI STUN service outside their public router, as its typically used for adoption/management of devices on the same private network. I'd personally connect any remotely managed sites via a VPN for this, but your in advanced use-case territory at this point and are therefore likely capable of figuring out a solution that fits your network.
    1 point
  23. Nice catch! I'm a Unifi users as well, but my controller runs on the USG. The Matrix container config does give you the option to reassign the STUN ports, so you can give that a shot and reflect the settings in your TURN config. If anyone has to do this, please report back if there are any issues! Worst case, you can pick one of the conflicting dockers and set their network type to 'Host'. Unrelated note: this configuration has an issue with enabling integrations. I think I can work around this by adding another port-forward rule and another entry to the Matrix nginx proxy config. Will update once I figure it out!
    1 point
  24. Slight update, for those who already followed along: I forgot one step Forward in both TCP and UDP ports 3478 to your unraid server Then in your matrix/homeserver.yaml file, configure TURN to point to your bridge, and give it a good secret using the methods described above: This is for the Matrix TURN server, which is used to connect VoIP/video calls correctly. Turning a riot chat into a video conference may fail with only 2 users if this isn't done!
    1 point
  25. Update you can now have dockers expanded on dashboard ( @capt.asic hope its kinda what you imagined ) Added Unraid Docker WebUI construct Allow folder renaming Only restart started dockers Still wanna do this but might be a soon™
    1 point
  26. Thanks! If you need to get in touch with the support team via Riot, you can connect directly to their main matrix server using their Riot install https://riot.im/app/ I just tested creating a matrix.org account via my hosted Riot client and didn't have any issues. Make sure your FW/NAT is allowing access from outside the firewall using the URL you intend to use for your Riot client.
    1 point
  27. That's a great question, and being kinda new to docker-composer, I'm not quite sure yet since i haven't had it up long enough to need to worry about that yet. When you bring up the containers with docker-compose, they download the images. I wonder if the following will do the trick: ``` cd /path/to/docker-jitsi-meet docker-compose pull docker-compose restart ``` Since its using images, that should 'in theory' pull down the latest images. If there are any config changes, it might be a good idea to do a `docker-compose build` as well. If anyone knows better, please chime in!
    1 point
  28. Maybe post in the Nerd Pack thread.
    1 point
  29. I added the following to my reverse proxy for the admin panel location /admin { return 404; } I only access the panel locally using the direct ip.
    1 point
  30. 1 point
  31. Adding on from my previous post, I wanted to access to other machines in my home network that I can't install tailscale on (IP cameras, etc). To solve for this, I made sure the "Network Type" was set to "bridge". I went in to the console for the Tailscale docker container and ran the following (my home network is 192.168.1.0/24 - change this to match your network): tailscale up --advertise-routes=192.168.1.0/24 After running this, I logged in to the Tailscale admin portal at https://login.tailscale.com/admin/machines and for my unraid box clicked the ... on the menu on the far right and click "Enable subnet routes" Back in the docker console I ran: vi /etc/sysctl.d/00-alpine.conf I added a line: net.ipv4.ip_forward=1 then saved the file. I ran the command: echo 0 | tee /proc/sys/net/ipv4/conf/tailscale0/rp_filter I ran the command: iptables -t nat -A POSTROUTING -j MASQUERADE I could then hit my internal IPs from an iPhone on LTE e.g. http://192.168.1.145 let me hit my IP cams web interface I rebooted and the settings persisted, so it seems to be a permanent setup now.
    1 point
  32. New release with some minor functional changes and a few bug fixes. This was mostly background stuff with the exception of adding a "Backup Now" button. v0.1.7 - 2019/12/22 Ms. Frizzle - fixed minor issues. - fixed paths requiring trailing slashes. - fixed backup location drop-down color when using black theme. - added additional logging. - added donate button. - added backup now button. - changed backup location drop-down start folder to /mnt/. - updated help. - updated readme. https://github.com/JTok/unraid.vmbackup/tree/v0.1.7 -JTok
    1 point
  33. Why not, indeed! Squid, you rock! Thanks for the quick response.
    1 point
  34. Why not just use curl or wget via the user scripts plugin at whatever cron schedule you choose?
    1 point
  35. hey guys, just started using this. Tried deleting a file in my keep directory on my server. I then went to restore it from Crashplan but it said it was a read only file system. Probably a permissions error or something, any ideas how to fix this? Sorry found the fix editing the container's storage permissions..
    1 point
  36. Our image doesn't use acme, which is a third party script. We use the official client, certbot. Honestly, GoDaddy is not very good at DNS services. I'd take cloudflare over any of those domain registrar provided DNS service any day. Cloudflare is free, very easy to switch to and propagates changes almost instantly. You're better off using cloudflare as your dns provider. I have domains bought from various providers like dynadot and name cheap, but they all point the name servers to cloudflare, which handles dns for me
    1 point
  37. Copy the .bash_profile to your flash (/boot/config/) and add the following line to your go file: ln -sf /boot/config/.bash_profile /root/.bash_profile This will create a link overwriting the original file and pointing to the new one on the flash. Changing something in the original location will be put on the flash automatically and thus survive a reboot.
    1 point
  38. I added the aliases to .bash_profile- # console coloring for kool kids PS1='\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ ' # if this is an xterm set the title to user@host:dir case "$TERM" in xterm*|rxvt*) PS1="\[\e]0;\u@\h: \w\a\]$PS1" ;; *) ;; esac # impersonate a user alias user="su -ls /bin/bash" alias v="ls -lA" # advanced copy aliases alias cp="gcp -g" alias mv="gmv -g" alias n="sudo -u nobody" alias ncp="sudo -u nobody gcp -g" alias nmv="sudo -u nobody gmv -g" How do I get them to survive a reboot?
    1 point
  39. chown -R nobody:users /mnt/user/unRAID/ appears to have resolved the SMB permission denied. The file were likely incorrectly owned because I used rsync, run as root, to copy them to /mnt/user/unRAID/ Thx
    1 point
  40. Same, I don't have a 4K TV, my wife can't tell the difference between 576p and 1080p and my daughter just tries to lick the screen, so for now, I'm going to ignore it too.....
    1 point
  41. i got it working already.. i see this address to the device is different to the other 2 which is pretty similar except last digit.. so i picked the other address and it is working.. thank you!
    1 point
  42. I had this issue as well recently, I found the only way to get rid of them was to go the actual disk where the files reside and delete them from there, so /mnt/diskx/Films/ instead of /mnt/user/Films/. When I did this I was able to delete the files successfully. Good luck
    1 point