Leaderboard

Popular Content

Showing content with the highest reputation on 04/05/21 in all areas

  1. You seem to believe that unRAID is a full Linux distribution. It is not. It may never implement users, permissions and security in the way you would expect of a full Linux distro or any other OS. As a special use appliance OS, unRAID does what it is expected to do in the way it was designed to do it. Are there issues and problems that need to be fixed? Yes, absolutely. Does unRAID need to be completely redesigned to fix these issue? No. Obviously, you can quit using unRAID at any time if it does not meet your needs. It is not for everyone and perhaps it does not do what you want or expect it to do. The hacks are a result of unRAID being used improperly rather than unRAID failing to function in the manner in which it was designed. I would expect to see more emphasis on educating and helping users to implement unRAID and its supporting infrastructure properly rather than a product redesign to address problems it was never intended to address.
    3 points
  2. This bug, perhaps? https://bugzilla.kernel.org/show_bug.cgi?id=211167
    2 points
  3. Step 2 gives me: 404. That’s an error. The requested URL was not found on this server. Not sure if google changed the way they do things.
    1 point
  4. UD does a network test before mounting remote shares. The test for the network being available was not successful. This check is after the array is started. The network should be available then. If the GUI is not reachable, UD cannot mount remote devices because the network is not ready. The UD test for the network being available is by trying to ping your gateway device for 30 seconds. If there is no response, UD thinks the network is not available. Generally the gateway is your router. Check your network setup in Unraid.
    1 point
  5. So I've been doing some more playing around, and I've got it working.. (kind of) I installed a VM on another host , followed your guide exactly, and... it worked! First try. I'm now able to log into Authelia & Nextcloud(which are hosted on my unraid) using the FreeIPA running on a VM from another non-unraid host. Any idea what could be preventing this from working on unraid, but working fine from another host? Nice to see your site is back up, I was finally able to sign up for that monthly membership. Thanks again for your hard work on the guides
    1 point
  6. LOL Yes, I do really love this motherboard. Thinking of buying a second for my other server, moving this Ryzen 9 over and downgrading my primary to a 65W TDP CPU like the Ryzen 7 3700x. This server only has 2U of workable space with the 12-bays in the back and my other server has a full 4U so I can put in a much better cooler and push the CPU without feeling uncomfortable about the fan noise or the temps. Thanks for looking at the logs and my stress level has come down quite a bit since things appear to be very stable at this point. If all the memory modules pass after rigorous testing, then I'll just put all 4 sticks in. If I start having problems again then it will be time to engage AsRock to see about RMA'ing the board and/or a possible BIOS update from them. I know they are a bit slow to release stable BIOS updates, but support seems to be pretty good with providing Beta BIOS fixes.
    1 point
  7. Ok hat funktioniert. Ich musste die Soundkarte af den gleichen Bus legen, aber eine andere functions hinterlegen. Falls einer da auch mal Hilfe braucht, jeder Zeit 🙂
    1 point
  8. As far as unRaid is concerned I guess it will likely be a case of which Linux kernel release includes this bug fix. and then which unRaid release picks up that kernel version.
    1 point
  9. It already has been fixed. See comments 24 and 31.
    1 point
  10. Was, wo, wer, wie? Hast keine einzige Frage benatwortet... Was willst du minen ETH, ETC, BTC, LTC,... Kennst du die CA App überhaupt? Komm mal weg von deinen VM's... Beschäftig dich doch mal mit Docker, viel Resourcenschonender.
    1 point
  11. OK, that would explain it! Replacing the cooler is now the priority. Your diagnostics from 0713 look much cleaner.
    1 point
  12. If I think about it, I'll take a pic of my BIOS, as you've also got to set T1 and T2 IIRC
    1 point
  13. Those mappings look OK. Why are you letting this happen? Unraid has no way to know how large a file will become when it chooses a disk for it. If a disk has more than Minimum Free for the share, that disk can be chosen, and if it runs out of space it will fail. You must set Minimum Free for each of your shares to larger than the largest file you expect to write for the share.
    1 point
  14. How much memory do you have in the server? This appears to me to be a RAM completely full issue.
    1 point
  15. Thank you JorgeB, that was the problem. I reset the directory to 777 and all appeared again with a restart. Thank you very much. I was really confused about this problem. I'll try upgrading again now.
    1 point
  16. Correct. You would use Wireguard for that. But, via Unraid.net you can access any VM's that are using VNC for video (ie: don't have a video card passed through)
    1 point
  17. It does appear to be fixed for 1st posts, still happended for a moved post though, didn't yet test after flagging a spammer.
    1 point
  18. Problem was caused by one of the cache devices dropping offline: Apr 4 18:50:50 M1171-NAS kernel: ata1: softreset failed (1st FIS failed) Apr 4 18:50:50 M1171-NAS kernel: ata1: limiting SATA link speed to 3.0 Gbps Apr 4 18:50:50 M1171-NAS kernel: ata1: hard resetting link Apr 4 18:50:55 M1171-NAS kernel: ata1: softreset failed (1st FIS failed) Apr 4 18:50:55 M1171-NAS kernel: ata1: reset failed, giving up Apr 4 18:50:55 M1171-NAS kernel: ata1.00: disabled There's a known issue with the onboard SATA controller in some Ryzen boards, look for a BIOS update, or use an add-on controller.
    1 point
  19. The problem is the filesystem in the destination disk: Apr 3 20:28:07 Tower kernel: REISERFS error (device md9): vs-5150 search_by_key: invalid format found in block 232203785. Fsck? Apr 3 20:28:07 Tower kernel: REISERFS (device md9): Remounting filesystem read-only Also good idea to convert all reiserfs disks to xfs, reiserfs is not recommended for v6.
    1 point
  20. Fractal Design launched an upgraded tray, there's also an adapter for existing trays.
    1 point
  21. Wer hat denn so kleine Server Spass bei Seite: Das Ergebnis entspricht bei einer Parity und einer Datenplatte _zufällig_ RAID-1. Ich vermute, dass es darum ging. Alles zu finden unter "How Parity works" in diesem Dokument. Sollte es Ausnahmen geben, dann stünden diese wohl darin: https://wiki.unraid.net/Parity#How_parity_works
    1 point
  22. Odd, pstate haven't effect .... in experience , that behavior usually due to BIOS have lock that. Check 10700 (non-k), Intel let user set the PL1 ( power limit ), so it really a bonus, you can turbo max it but consume over 200W. So, I suppose BIOS have unleash its performance in default. https://www.techpowerup.com/review/intel-core-i7-10700/22.html Things are different once you start unlocking the power limit. Intel intended for the Core i7-10700 to operate at 65 W, which is simply way too low for this 8-core/16-thread processor. In order to achieve their 65 W TDP promise, Intel has set the PL1 power limit to 65 W. For short, in bursty workloads the PL2 power limit will override PL1 for a few seconds as it is set at a generous 224 W. Manually adjusting the power limit is possible on all multiplier-locked "Comet Lake" processors; on all motherboards, with all chipsets. While in previous reviews, we saw very little benefit from playing with those power limits, this capability has turned into a wonderful new overclocking knob for the Core i7-10700.
    1 point
  23. Wanted to just comment and say THANK YOU! I was having the exact same issue. Not sure why this happened and never could find an answer.
    1 point
  24. Thank you, went through everything in the bios so I think there is something physically at fault here, will need to try different card or different motherboard I think to see if it still works.
    1 point
  25. Post your docker run command for your rtorrent docker as explained at the very first link in the Docker FAQ
    1 point
  26. @ich777Thanks a lot. Update of TBS driver works perfectly!
    1 point
  27. Delete .cfg files in config/shares on flash that don't correspond to any of your user shares.
    1 point
  28. rtorrent has trashed your system. It's consuming an insane amount of memory right now. Apps - Previous Apps If you are manually making changes inside the container (ie: docker exec -it rutorrent /bin/bash or using the container's console), then after a reinstallation or upgrade of the container, those changes will be gone. This is one of the big features touted by docker Are you sure that you've got rutorrent set up correctly? As in it's not downloading to RAM?
    1 point
  29. 1 point
  30. 1 point
  31. JorgeB - TY Ran a filesystem check, then finally converted to XFS. Working again!
    1 point
  32. I am having issues with the latest Docker image and i cannot access the application, if i look in the log file located at '/config/supervisord.log' then i see the following message:- '/usr/lib/jvm/java-8-openjdk/jre' is not a valid Java environment path Q. What does it mean and how can i fix it? A. See Q10 from the following link for the solution:- https://github.com/binhex/documentation/blob/master/docker/faq/general.md EDIT - unRAID 6.9.2 has just been released, this includes the latest version of Docker, which in turn includes the latest version of runc, so if you are seeing the message above then the simplest solution is to upgrade to v6.9.2
    1 point
  33. I'm assuming you are on 6.9.0-rc2? If you hover over the disabled checkbox you should get a tooltip saying "In use by Unraid". Go to Settings -> Network Settings and remove the nic from any bonds (note: you will need to stop the array to make any changes to the network setup). Once it is no longer in use by Unraid, the checkbox will be active. If you get stuck, please upload your diagnostics (from Tools -> Diagnostics)
    1 point
  34. I'm not asking that, I'm sure you did. I presume your current situation is that you CAN start the array when typing the passphrase at the GUI, but can not change it using cryptsetup and / or my script. Is my understanding correct? Can you tell me what types of characters are in your passphrase? Not asking to share the phrase obviously, just the type of characters it is comprised of: - Does it have non Alphanumeric characters? - Does it have non-ASCII characters (i.e. from a code page different than Latin)? If so can you give an example of such a character? (again do not reveal your real phrase, just the nature of the characters in it) EDIT: Can you PM me a passphrase that is LIKE yours in terms of character set? Again, not even close to your real one, just something that I can test with, and that is structured similarly to the passphrase you're having an issue with.
    1 point
  35. I finally found a fix, that works with my machine! I added the following code to the /flash/config/go file: #fix video for VM echo 0 > /sys/class/vtconsole/vtcon0/bind echo 0 > /sys/class/vtconsole/vtcon1/bind echo efi-framebuffer.0 > /sys/bus/platform/drivers/efi-framebuffer/unbind Those lines unbind the console & by adding it to /flash/config/go will execute this piece of code on every boot of the system.
    1 point
  36. Finally got the update working also on the 3617x - You need to run this script in order to do the latest DSM updates: https://xpenology.com/forum/topic/28183-running-623-on-esxi-synoboot-is-broken-fix-available/ However, if Jun's script is re-run after the system is fully started, everything is as it should be. So extracting the script from the loader, and adding it to post-boot actions appears to be a solution to this problem: Download the attached FixSynoboot.sh script (if you cannot see it attached to this post, be sure you are logged in) Copy the file to /usr/local/etc/rc.d chmod 0755 /usr/local/etc/rc.d/FixSynoboot.sh Thus, Jun's own code will re-run after the initial boot after whatever system initialization parameters that break the first run of the script no longer apply. This solution works with either 1.03b or 1.04b and is simple to install. This should be considered required for a virtual system running 6.2.3, and it won't hurt anything if installed or ported to another environment. 1) Check file is in temp dir ls /volume1/Temp/FixSynoboot.sh sudo -i cp /volume1/Temp/FixSynoboot.sh /usr/local/etc/rc.d chmod 0755 /usr/local/etc/rc.d/FixSynoboot.sh ls -la /usr/local/etc/rc.d/FixSynoboot.sh -rwxr-xr-x 1 root root 2184 May 18 17:54 FixSynoboot.sh Ensure the file configuration is correct, reboot the nas and FixSynoboot will be enabled. That's it I am now running: I even did a test running the new migration tool, migrating all 8-9TB and all apps and configuration from my own Synology 3617 Just wanted to try to see if I could create a full running backup on my Unraid server Sofar only thing that doesn't seem to work is my But again not sure I want to run virtual machines on a virtual NAS LOL! But anyway if someone knows how to fix this it could be fun to do a benchmark
    1 point