Leaderboard

Popular Content

Showing content with the highest reputation since 12/06/20 in Report Comments

  1. @limetech I solved this issue as follows and successfully tested it in: Unraid 6.9.2 Unraid 6.10.0-rc1 Add this to /boot/config/go (by Config Editor Plugin): # ------------------------------------------------- # RAM-Disk for Docker json/log files # ------------------------------------------------- # create RAM-Disk on starting the docker service sed -i '/^ echo "starting \$BASE ..."$/i \ # move json/logs to ram disk\ rsync -aH --delete /var/lib/docker/containers/ ${DOCKER_APP_CONFIG_PATH%/}/containers_backup\ mount -t tmpfs tmpfs /var/lib/docker/containers\ rsync -aH --delete ${DOCKER_APP_CONFIG_PATH%/}/containers_backup/ /var/lib/docker/containers\ logger -t docker RAM-Disk created' /etc/rc.d/rc.docker # remove RAM-Disk on stopping the docker service sed -i '/^ # tear down the bridge$/i \ # backup json/logs and remove RAM-Disk\ rsync -aH --delete /var/lib/docker/containers/ ${DOCKER_APP_CONFIG_PATH%/}/containers_backup\ umount /var/lib/docker/containers\ rsync -aH --delete ${DOCKER_APP_CONFIG_PATH%/}/containers_backup/ /var/lib/docker/containers\ logger -t docker RAM-Disk removed' /etc/rc.d/rc.docker # Automatically backup Docker RAM-Disk sed -i '/^<?PHP$/a \ $sync_interval_minutes=30;\ if ( ! ((date('i') * date('H') * 60 + date('i')) % $sync_interval_minutes) && file_exists("/var/lib/docker/containers")) {\ exec("mkdir /var/lib/docker_bind");\ exec("mount --bind /var/lib/docker /var/lib/docker_bind");\ exec("rsync -aH --delete /var/lib/docker/containers/ /var/lib/docker_bind/containers");\ exec("umount /var/lib/docker_bind");\ exec("rmdir /var/lib/docker_bind");\ exec("logger -t docker RAM-Disk synced");\ }' /usr/local/emhttp/plugins/dynamix/scripts/monitor Optional: Limit the Docker LOG size to avoid using too much RAM: Reboot server Notes: By this change /var/lib/docker/containers, which contains only status and log files, becomes a RAM-Disk and therefore avoids wearing out your SSD and allows a permanent sleeping SSD (energy efficient) It automatically syncs the RAM-Disk every 30 minutes to your default appdata location (for server crash / power-loss scenarios). If container logs are important to you, feel free to change the value of "$sync_interval_minutes" in the above code to a smaller value to sync the RAM-Disk every x minutes. If you like to update Unraid OS, you should remove the change from the Go File until it's clear that this enhancement is still working/needed! Your Reward: After you enabled the docker service you can check if the RAM-Disk has been created (and its usage): Screenshot of changes in /etc/rc.d/rc.docker and /usr/local/emhttp/plugins/dynamix/scripts/monitor
    16 points
  2. I like to highlight other improvements available in 6.10, which are maybe not so obvious to spot from the release notes and some of these improvements are internal and not really visible. - Event driven model to obtain server information and update the GUI in real-time The advantage of this model is its scalability. Multiple browsers can be opened simultaneously to the GUI without much impact In addition stale browser sessions won't create any CSRF errors anymore People who keep their browser open 24/7 will find the GUI stays responsive at all times - Docker labels Docker labels are added to allow people using Docker compose to make use of icons and GUI access Look at a Docker 'run' command output to see exactly what labels are used - Docker custom networks A new setting for custom networks is available. Originally custom networks are created using the macvlan mode, and this mode is kept when upgrading to version 6.10 The new ipvlan mode is introduced to battle the crashes some people experience when using macvlan mode. If that is your case, change to ipvlan mode and test. Changing of mode does not require to reconfigure anything on Docker level, internally everything is being taken care off. - Docker bridge network (docker0) docker0 now supports IPv6. This is implemented by assigning docker0 a private IPv6 subnet (fd17::/64), similar to what is done for IPv4 and use network translation to communicate with the outside world Containers connected to the bridge network now have both IPv4 and IPv6 connectivity (of course the system must have IPv6 configured in the network configuration) In addition several enhancements are made in the IPv6 implementation to better deal with the use (or no-use) of IPv6 - Plugins page The plugins page now loads information in two steps. First the list of plugins is created and next the more time consuming plugin status field is retrieved in the background. The result is a faster loading plugins page, especially when you have a lot of plugins installed - Dashboard graphs The dashboard has now two graphs available. The CPU graph is displayed by default, while the NETWORK graph is a new option under Interface (see the 'General Info' selection) The CPU graph may be hidden as well in case it is not desired Both graphs have a configurable time-line, which is by default 30 seconds and can be changed independently for each graph to see a longer or shorter history. Graphs are updated in real-time and are useful to observe the behavior of the server under different circumstances
    14 points
  3. Someone please help me understand this? What if I don't wanna associate my keys and my home installs with my unraid forum account? I really like my privacy honestly and what is is my home have no business being associated with any cloud or external servers. This is a very slippery slope and I just don't like it. Is there an option to continue be offline just the way I am right now? I just don't want to be part of this new ecosystem unraid is creating. I trust my privacy and I trust no one, I am sorry..... And there’s absolutely no reason why you can’t support both ways of activating / running unraid. I should not be forced to connect with you if I have a valid key. "UPC and My Servers Plugin The most visible new feature is located in the upper right of the webGUI header. We call this the User Profile Component, or UPC. The UPC allows a user to associate their server(s) and license key(s) with their Unraid Community forum account. Starting with this release, it will be necessary for a new user to either sign-in with existing forum credentials or sign-up, creating a new account via the UPC in order to download a Trial key. All key purchases and upgrades are also handled exclusively via the UPC"
    12 points
  4. For Unraid version 6.10 I have replaced the Docker macvlan driver for the Docker ipvlan driver. IPvlan is a new twist on the tried and true network virtualization technique. The Linux implementations are extremely lightweight because rather than using the traditional Linux bridge for isolation, they are associated to a Linux Ethernet interface or sub-interface to enforce separation between networks and connectivity to the physical network. The end-user doesn't have to do anything special. At startup legacy networks are automatically removed and replaced by the new network approach. Please test once 6.10 becomes available. Internal testing looks very good so far.
    12 points
  5. Since the UPC seems to be stirring up a lot of adverse reaction, maybe the easiest option is to set up a setting under either Settings->Identification or Settings->Management Access (whichever is deemed most appropriate) to remove the Login prompt from the top of the GUI? It can then be defaulted to Enabled until explicitly disabled by the user so new users see it is an option. That might also help with making it clearer that this is purely an optional feature
    10 points
  6. I wonder if I need to enter the NO HEALTHCHECK parameter for all these containers? Will they work stably after that?
    9 points
  7. No. If you have the latest version, you are good to go.
    8 points
  8. I'll add it back, don't want to get between anyone and their WINE
    7 points
  9. Since you mention "for others to see", I take it as giving me right to comment (after all it IS in a public forum). So let me comment on this after reading your original post too. 1) Disclaimer: I am not taking the side of Limetech. I don't care. I had my own rough times in the past (with Tom too IIRC)... many years ago. Don't even remember why any more. Back then I "voted" with my decision. I stopped using unRAID for years. Yet I returned because it became what I dreamt it should be before I stopped using it. So being first and foremost a consumer, not a fanboy nor a hater, I just returned. My original Pro license waited for me patiently. 2) Since you are talking about "tone"... Your tone in your first post and this post is quite a Karen. You are only ONE customer. Who made you our representative and the right to speak for us? Who told you we want this removed (even if we don't use it, I don't either). It doesn't bother me. It just stays there, who cares. 3) I don't see any threat whatsoever by LT. Maybe you mean "treat", but still, I don't see an issue. 4) LT is a business, as you said. They make things, we buy them, they support them indefinitely ON the price we originally bought them (no service fees). So why would they be grateful, or would we be grateful? $$$ = product. And I bet you have the product already. It is a transaction - as simple as that. Yet, they stand by their clients all right and do it for years (and this is not proven by removing something nobody else asked to remove than entitled-you). 5) Also, since they are a business, it is in the end their choice if they want to actively promote a new feature (their "cloud" system) if it is not too intrusive. So that login up in the corner and the OPTIONAL plugin, is not what I would call "intrusive". 6) Nobody is forcing you to update unRAID to next version. Stay on the current one. Remove unRAID for all we care. 7) If this login button and menu is (or was) a real problem, I am sure someone will step in with a tiny plugin (like the one that widens the interface for super-wide screens), that removes it. Or you can try making such a plugin. 8 ) Back to tone. I am sure if your original post was something like "this thing on the top right about logging in... could you please make hide-able, maybe by a toggle in the settings in some future version, for us OCD people?". This possibly would get a better reply. Cheers.
    5 points
  10. One comment on this release. If you're one of the (very rare) users who still leverages the Template Repositories section, this has been entirely removed See here for how to manage your private containers if you used Template Repositories
    5 points
  11. Interesting. Unraid OS 6.9.1 is on kernel 5.10.21 and the referenced patch is not applied. Upcoming 6.9.2 release is on kernel 5.10.27 which does have the patch. Working on finalizing the release now.
    5 points
  12. I've done some digging on this - here's what I found. Mount unraid share system on my mac and check its spotlight status: [macbook-pro]:~ $ mdutil -s /Volumes/system /System/Volumes/Data/Volumes/system: Server search enabled. [macbook-pro]:~ $ But as best I can tell "server search" is not in fact enabled. Turns out samba 4.12.0 changed this search-related default: Note that when upgrading existing installations that are using the previous default Spotlight backend Gnome Tracker must explicitly set "spotlight backend = tracker" as the new default is "noindex". If I add the following to SMB extras: [global] spotlight backend = tracker in addition to this share-specific code: [system] path = /mnt/user/system spotlight = yes Search works again! When I check spotlight status I get the following: [macbook-pro]:~ $ mdutil -s /Volumes/system /System/Volumes/Data/Volumes/system: Indexing disabled. [macbook-pro]:~ $ Hopefully this is useful toward a general fix. I'd rather avoid a custom entry for each share.
    5 points
  13. @limetech Here's what I did: Deleted the two files from /boot/config: rsyslog.cfg rsyslog.conf Rebooted Started the Array Reconfigured the Syslog settings Hit Apply Checked the Syslog and saw that rsyslogd started Verified that there was a file in my share Verified that data was in the file
    5 points
  14. NFSv4 is enabled in this release and UD will now mount remote shares with NFSv4. Go to the UD settings and set the NFS version to NFSv4 and all UD mounted remote NFS shares will be mounted with NFSv4. You'll have to unmount and remount any remote NFS shares to get them mounted with v4.
    4 points
  15. That works, I have also tried yesterday to add the following to `go` file: /usr/bin/sed -i -e 's/#HandleLidSwitch=suspend/HandleLidSwitch=ignore/g' /etc/elogind/logind.conf /etc/rc.d/rc.elogind restart This will not work during boot since the laptop already sleeps until go file is executed, if I wake up the laptop manually after it sleeps during boot it will not get back to sleep. Is there a way to make the change before `elogind` runs?
    4 points
  16. great job to the dev team 🙂
    4 points
  17. Can I please ask limetech for some FAQ or written details around the existing users / licenses behaviors / expectations / changes in light of this upgrade? Is really not clear to me who does what, just assumptions at this point. I for one, will opt out from associating any of my licenses with this forum credentials and that's a show stopper for me. I value my privacy and my control more than any social or cloud services and I will not sign my life away down the road to some vague license agreement. Not pointing at limetech but tech history proved over and over again that we're going down a very slippery slope when extend our own devices over some fashion of cloud services. I simply don't trust that model, full, stop, period. This is not what I signed up for and I would like to keep it that way. I can appreciate some of the business benefits explained and I respect that, but also one have to respect our privacy.
    4 points
  18. "Starting with this release, it will be necessary for a new user to either sign-in with existing forum credentials or sign-up, creating a new account via the UPC in order to download a Trial key. All key purchases and upgrades are also handled exclusively via the UPC." I do also think this needs more clarification for current users who don't want to sign or associate their servers with UPC regarding key management. How it will be handled in the future etc...
    4 points
  19. Where do you think this is "heading"? Any "cloud" services and features we offer are, and will continue to be completely "opt in" with the default being "opt out".
    4 points
  20. Until now every Unraid 6.x version relied on traditional polling of the server to update the GUI in real-time. On the Dashboard there are multiple fields which are getting updated regularly. It is the task of the browser to initiate each time a poll request to obtain the new information and update the GUI accordingly. Polling puts load on both the browser and server, and may consume more memory over time (depending on the browser). Starting with Unraid version 6.10 the traditional polling mechanism is replaced by a websocket event driven model using Nchan. An event driven model has a number of key advantages. - It allows the server to send information when changes take place (better efficiency) - Multiple clients can be served at the same time without huge impact on the server load (better scalability) - A client only needs to act when new information is received (better responsiveness) The event driven model also solves the issue of stale sessions when people open multiple browsers (on different computers) and forget to close them after usage. This resulted in csrf token mismatches when the server was restarted. So far all testing with the event driven model looks very promising and a solid improvement!
    4 points
  21. Executing any kind of SMART operation increments both number I/O's to the device (in this case Reads) and number sectors transferred (in this case sectors read). This is true whether device is in standby or not. HOWEVER, I have a fix for this coming in 6.9.1
    4 points
  22. These spinning issues are addressed in -rc2
    4 points
  23. 4 points
  24. No. All UD configuration settings are retained.
    4 points
  25. Just a little feedback on upgrading from Unraid Nvidia beta30 to beta35 with Nvidia drivers plugin. The process was smooth and I see no stability or performance issue after 48h, following these steps : - Disable auto-start on "nvidia aware" containers (Plex and F@H for me) - Stop all containers - Disable Docker engine - Stop all VMs (none of them had a GPU passthrough) - Disable VM Manager - Remove Unraid-Nvidia plugin - Upgrade to 6.9.0-beta35 with Tools>Update OS - Reboot - Install Nvidia Drivers plugin from CA (be patient and wait for the "Done" button) - Check the driver installation (Settings>Nvidia Drivers, should be 455.38, run nvidia-smi under CLI). Verify the GpuID is unchanged, which was the case for me, otherwise the "NVIDIA_VISIBLE_DEVICES" variable should be changed accordingly for the relevant containers - Reboot - Enable VM Manager, restart VMs and check them - Enable Docker engine, start Plex and F@H - Re-enable autostart for Plex and F@H All this is perhaps a bit over-cautious, but at least I can confirm I got the expected result, i.e. an upgraded server with all functionalities up and running under 6.9.0-beta35 !
    4 points
  26. Below I include my Unraid (Version: 6.10.0-rc1) "Samba extra configuration". This configuration is working well for me accessing Unraid shares from macOS Monterey 12.0.1 I expect these configuration parameters will work okay for Unraid 6.9.2. The "veto" commands speed-up performance to macOS by disabling Finder features (labels/tags, folder/directory views, custom icons etc.) so you might like to include or exclude these lines per your requirements. Note, there are problems with samba version 4.15.0 in Unraid 6.10.0-rc2 causing unexpected dropped SMB connections… (behavior like this should be anticipated in pre-release) but fixes expected in future releases. This configuration is based on a Samba configuration recommended for macOS users from 45Drives here: KB450114 – MacOS Samba Optimization. #unassigned_devices_start #Unassigned devices share includes include = /tmp/unassigned.devices/smb-settings.conf #unassigned_devices_end [global] vfs objects = catia fruit streams_xattr fruit:nfs_aces = no fruit:zero_file_id = yes fruit:metadata = stream fruit:encoding = native spotlight backend = tracker [data01] path = /mnt/user/data01 veto files = /._*/.DS_Store/ delete veto files = yes spotlight = yes My Unraid share is "data01". Give attention to modifying the configuration for your particular shares (and other requirements). I hope providing this might help others to troubleshoot and optimize SMB for macOS.
    3 points
  27. Just want you guys to know that we're tracking all of these VM issues and I'm looking into them this week. Thank you for the reports!
    3 points
  28. We are not going to remove it and your server functions identically whether you "sign in" or not, with exception of provisioning or renew of a Let's Encypt certificate, which evidently you are not interested in anyway. Nothing is being "pushed down anyone's throats". Just don't sign-in but nothing is exchanged which we don't already know (like your key/GUID) or that we care about (like your server name or LAN IP), those are transmitted for your convenience. Do you use Docker? Do you use plugins? Do you use automatic check for updates? Do you have NTP enabled? All those services contact resources on the internet. And honestly, we are lot more forthcoming in the nature of the data transfer happening than some of those might be. Lastly, out of respect, if anyone wants to discuss this further, please create a separate topic to do so.
    3 points
  29. I wont annoy anyone by posting my objection to the UPC again, but in case it makes any difference to the company, for whom I have had great respect and good feelings for about 11 years, this will represent the end of my support. I will not upgrade from my current state. I have ZERO interest in having my servers connected to the internet except for one application on my backup server. There is no need to take any risk whatsoever of allowing some mistake/mismanagement/malicious attack/ whatever at Lime technology and _especially_ over this "for information only" forum. I am stunned that connecting registration on this forum directly to our server license and information was even floated except over a beers. I really can't believe this is being considered. I suppose the modern way of things is subscriptions to gouge every last dime out of customers at a seemingly low price month by month but I am rejecting it from microsoft and will reject it here. I am quite happy with my purchase, have recommended UNRAID uncounted times to others and several friends are now users but that is at an end. I will remain at my current version of unraid that that's that. It sounds like i need also to delete this forum account, unfortunately. I am certain noone gives a rat's but I thought I would clarify my position before signing off of the forum. Why not just charge for version upgrades instead? Is that because people might decide they dont need the current version and you'd like to charge them anyway? At the price of the security of my servers? I just dont understand. I have happily paid for my licenses and was actually considering purchasing a third, but man this will get very expensive very quickly if i pay for it every month. what happens when i stop paying?
    3 points
  30. There is a lot going on in the release, and a lot of good! Some mixed sentiment on the UPC and My Server stuff. Firstly the My Server stuff is fine, an optional additional service people can use to remotely monitor one or more servers. Great stuff useful for those that need or want this. The UPC stuff is a little more complex. I changed my key today, the old way, and it was super simple barely an inconvenience. I'll outline my concerns with this direction, take them as you will. UPC is linking to a forum. It could be that the forum backend is the core authentication system / CRM or the like, but it seems an odd choice to me. If a server is authenticated via UPC an open web socket is maintained. Generally not a big deal, but it's another thing to be exploited and as others have pointed out didn't work out so well for other companies. All information is useful to a hacker, no matter how little data may be captured if there is a breach it is exposing potentially vast configurations, IPs, and so on. On the configuration backups, why a private repo? This seems odd to me, are these encrypted per server? Wouldn't just end to end encrypted file blobs be more secure, regardless of saying "it doesn't include files with sensitive info". No company regardless of design or merit is immune to breaches, hacks, or acquisitions. While it's clear now that if you have a valid key you do not need to authenticate with UPC (forum), this is pretty much how all non-cloud authentications go to die. I've seen, you've seen it... And I get it, from a business perspective, it's easier for you to manage centrally, oversee, and move towards the subscription model. Confidence that a path like this isn't in the future would ease many, especially in the area of data storage where moving is not always trivial. Are you GDPR compliant, or similar data protection schemes (kind of not specific to the release, just generally) Are you ISO27001 and SOC certified such that we can be sure your development pipelines to your infrastructure won't be compromised with active connections to our servers? These are my concerns, the features and functions of Unraid in this release are great. Thanks for the work put into them
    3 points
  31. I was having a lot of issues with transcodes on Intel iGPU on Unraid 6.9.2 so I upgraded to the RC to see if it would help and ran into this exact issue. UPDATE: Plex server version 1.25.0.5220 solves the issue. If using linuxserver.io's container, just make sure your VERSION environment variable is set to 'latest' and you should get it. Previous version of this post is quoted below, but the info is no longer relevant.
    3 points
  32. Thought I'd give an update. My system has an 11th Gen i9-11900K. In Unraid 6.9.2 (based on Linux kernel 5.10.28), I created this file on the flash: config/modprobe.d/i915.conf containing this text to activate the experimental i915 drivers for this GPU: options i915 force_probe=4c8a and Plex was able to do hardware transcoding. In some of the earlier private betas of 6.10, this worked as well. Starting with 6.10.0-rc1 (kernel 5.13.8) Plex was unable to do hardware transcoding on this system (it works on 9th and 10th gen Intel CPUs, just not 11th gen.) Internally today we are up to kernel 5.13.12 and Plex still will not do hardware transcoding on this system. In the 'Plex Media Server.log' it reports: TPU: hardware transcoding: enabled, but no hardware decode accelerator found On the plus side, you no longer need to create an i915.conf file with those custom options, the GPU activates right out of the box. And an interesting data point, this Jellyfin docker does hardware transcoding beautifully on the 6.10 rc's: https://forums.unraid.net/topic/102787-support-ich777-jellyfin-amdintelnvidia/ Now I'm not suggesting that die hard Plex fans need to switch to Jellyfin, I don't intend to. Just saying that the Linux drivers for the latest Intel CPU/GPUs are still in flux and for whatever reason, Jellyfin works with them and Plex does not. I do not know if a future Linux kernel will solve the problem, or if it will take an update from Plex. But I do not have high hopes for the current version of Plex doing hardware transcoding in rc2 on the latest Intel CPUs. Update - For completeness I will add that I am using the LSIO Plex Container: https://forums.unraid.net/topic/40463-support-linuxserverio-plex-media-server/ and Plex itself is currently (as of 8/25/21) version 1.24.1.4931. I have a Plex Pass.
    3 points
  33. I wonder if it's as simple as the "bluez-firmware: version 1.2" upgrade in 6.10.0-rc1 causing the issue as the NMBluezManager is a different version on the two logs you've attached?
    3 points
  34. Sure we can make that change for rc2
    3 points
  35. 👍 I don't understand this part. Is it still possible to use a paid license without internet access or not? And why is it needed to have an account for security-related notifications? Why don't you simply use the e-mail address which was used to buy the license (or the newsletter)?! So I'm forced to use My Servers if I want to receive security notifications?! And how is it possible to pull data from my server if I did not open any ports? You explained it through a reverse-proxy relay. This means a registered server has a 24/7 connection to the relay?! Qnap and Ubiquiti proved that it is a bad idea to use such services and having a random DDNS url with a random port is only security through obscurity. This is why I don't plan to use My Servers.
    3 points
  36. I don't see why this is a privacy concern in any way... The process is super simple and I also used it a few days ago to replace my key and it is way easier to replace your key that way. Btw you had to register with a mail account anyways and this process was more complicated in the past from my perspective. From my perspective this is a super simple way to get your trail key, buy or even replace it. Also please note that there is nothing that communicates constantly with the Forums or better speaking the so much hated "Cloud". If you want to have access to your server and manage it from the Forums so that the stats are displayed in the "My Servers" section on the Forums you have to install the My Servers plugin from the CA App, if you don't want this then don't install it. Just my 2cents.
    3 points
  37. I also do not like where this is heading. One of the reasons I chose unraid is because how I can keep it local. The less I put out to the open world, the better. If this is the way forward, I will be staying on 6.9 until I can find and implement a solution that lets me off the cloud as much as possible.
    3 points
  38. It doesn't matter, both scenarios work. WireGuard keeps on working as before with your current settings
    3 points
  39. 3 points
  40. Manged to catch this today. With the lightest of google searches it looks like it may be a bug/regression in the kernel. I very well could be wrong but maybe? https://askubuntu.com/questions/1293945/20-10-complete-system-freeze-with-general-protection-fault-smp-nopti https://www.spinics.net/lists/linux-nfs/msg78091.html https://www.spinics.net/lists/amd-gfx/msg48596.html Jun 12 14:00:01 thelibrary kernel: Jun 12 14:00:44 thelibrary kernel: general protection fault, probably for non-canonical address 0x1090000ffffff76: 0000 [#1] SMP NOPTI Jun 12 14:00:44 thelibrary kernel: CPU: 6 PID: 10937 Comm: qbittorrent-nox Tainted: P S W O 5.10.28-Unraid #1 Jun 12 14:00:44 thelibrary kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X470D4U, BIOS L4.21 04/15/2021 Jun 12 14:00:44 thelibrary kernel: RIP: 0010:nf_nat_setup_info+0x129/0x6aa [nf_nat] Jun 12 14:00:44 thelibrary kernel: Code: ff 48 8b 15 ef 6a 00 00 89 c0 48 8d 04 c2 48 8b 10 48 85 d2 74 80 48 81 ea 98 00 00 00 48 85 d2 0f 84 70 ff ff ff 8a 44 24 46 <38> 42 46 74 09 48 8b 92 98 00 00 00 eb d9 48 8b 4a 20 48 8b 42 28 Jun 12 14:00:44 thelibrary kernel: RSP: 0018:ffffc90000338700 EFLAGS: 00010202 Jun 12 14:00:44 thelibrary kernel: RAX: ffff88818b422f06 RBX: ffff888108b21a40 RCX: 0000000000000000 Jun 12 14:00:44 thelibrary kernel: RDX: 01090000ffffff76 RSI: 000000003f50ed19 RDI: ffffc90000338720 Jun 12 14:00:44 thelibrary kernel: RBP: ffffc900003387c8 R08: 0000000098f45bae R09: ffff88813dd40620 Jun 12 14:00:44 thelibrary kernel: R10: 0000000000000348 R11: ffffffff815cbe4b R12: 0000000000000000 Jun 12 14:00:44 thelibrary kernel: R13: ffffc90000338720 R14: ffffc900003387dc R15: ffffffff8210b440 Jun 12 14:00:44 thelibrary kernel: FS: 0000146c98419700(0000) GS:ffff88881e980000(0000) knlGS:0000000000000000 Jun 12 14:00:44 thelibrary kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jun 12 14:00:44 thelibrary kernel: CR2: 0000150d3d688320 CR3: 000000020149a000 CR4: 0000000000350ee0 Jun 12 14:00:44 thelibrary kernel: Call Trace: Jun 12 14:00:44 thelibrary kernel: <IRQ> Jun 12 14:00:44 thelibrary kernel: ? fq_enqueue+0x25b/0x4e8 Jun 12 14:00:44 thelibrary kernel: ? igb_xmit_frame_ring+0x7c5/0x8fd [igb] Jun 12 14:00:44 thelibrary kernel: ? __ksize+0x15/0x64 Jun 12 14:00:44 thelibrary kernel: ? krealloc+0x26/0x7a Jun 12 14:00:44 thelibrary kernel: nf_nat_masquerade_ipv4+0x10b/0x131 [nf_nat] Jun 12 14:00:44 thelibrary kernel: masquerade_tg+0x44/0x5e [xt_MASQUERADE] Jun 12 14:00:44 thelibrary kernel: ? __qdisc_run+0x21d/0x3c9 Jun 12 14:00:44 thelibrary kernel: ipt_do_table+0x51a/0x5c0 [ip_tables] Jun 12 14:00:44 thelibrary kernel: ? __dev_queue_xmit+0x4d9/0x501 Jun 12 14:00:44 thelibrary kernel: ? fib_validate_source+0xb0/0xda Jun 12 14:00:44 thelibrary kernel: nf_nat_inet_fn+0xe9/0x183 [nf_nat] Jun 12 14:00:44 thelibrary kernel: nf_nat_ipv4_out+0xf/0x88 [nf_nat] Jun 12 14:00:44 thelibrary kernel: nf_hook_slow+0x39/0x8e Jun 12 14:00:44 thelibrary kernel: nf_hook+0xab/0xd3 Jun 12 14:00:44 thelibrary kernel: ? __ip_finish_output+0x146/0x146 Jun 12 14:00:44 thelibrary kernel: ip_output+0x7d/0x8a Jun 12 14:00:44 thelibrary kernel: ? __ip_finish_output+0x146/0x146 Jun 12 14:00:44 thelibrary kernel: ip_forward+0x3f1/0x420 Jun 12 14:00:44 thelibrary kernel: ? ip_check_defrag+0x18f/0x18f Jun 12 14:00:44 thelibrary kernel: ip_sabotage_in+0x43/0x4d [br_netfilter] Jun 12 14:00:44 thelibrary kernel: nf_hook_slow+0x39/0x8e Jun 12 14:00:44 thelibrary kernel: nf_hook.constprop.0+0xb1/0xd8 Jun 12 14:00:44 thelibrary kernel: ? l3mdev_l3_rcv.constprop.0+0x50/0x50 Jun 12 14:00:44 thelibrary kernel: ip_rcv+0x41/0x61 Jun 12 14:00:44 thelibrary kernel: __netif_receive_skb_one_core+0x74/0x95 Jun 12 14:00:44 thelibrary kernel: netif_receive_skb+0x79/0xa1 Jun 12 14:00:44 thelibrary kernel: br_handle_frame_finish+0x30d/0x351 Jun 12 14:00:44 thelibrary kernel: ? br_pass_frame_up+0xda/0xda Jun 12 14:00:44 thelibrary kernel: br_nf_hook_thresh+0xa3/0xc3 [br_netfilter] Jun 12 14:00:44 thelibrary kernel: ? br_pass_frame_up+0xda/0xda Jun 12 14:00:44 thelibrary kernel: br_nf_pre_routing_finish+0x23d/0x264 [br_netfilter] Jun 12 14:00:44 thelibrary kernel: ? br_pass_frame_up+0xda/0xda Jun 12 14:00:44 thelibrary kernel: ? br_handle_frame_finish+0x351/0x351 Jun 12 14:00:44 thelibrary kernel: ? nf_nat_ipv4_pre_routing+0x1e/0x4a [nf_nat] Jun 12 14:00:44 thelibrary kernel: ? br_nf_forward_finish+0xd0/0xd0 [br_netfilter] Jun 12 14:00:44 thelibrary kernel: ? br_handle_frame_finish+0x351/0x351 Jun 12 14:00:44 thelibrary kernel: NF_HOOK+0xd7/0xf7 [br_netfilter] Jun 12 14:00:44 thelibrary kernel: ? br_nf_forward_finish+0xd0/0xd0 [br_netfilter] Jun 12 14:00:44 thelibrary kernel: br_nf_pre_routing+0x229/0x239 [br_netfilter] Jun 12 14:00:44 thelibrary kernel: ? br_nf_forward_finish+0xd0/0xd0 [br_netfilter] Jun 12 14:00:44 thelibrary kernel: br_handle_frame+0x25e/0x2a6 Jun 12 14:00:44 thelibrary kernel: ? br_pass_frame_up+0xda/0xda Jun 12 14:00:44 thelibrary kernel: __netif_receive_skb_core+0x335/0x4e7 Jun 12 14:00:44 thelibrary kernel: __netif_receive_skb_one_core+0x3d/0x95 Jun 12 14:00:44 thelibrary kernel: process_backlog+0xa3/0x13b Jun 12 14:00:44 thelibrary kernel: net_rx_action+0xf4/0x29d Jun 12 14:00:44 thelibrary kernel: __do_softirq+0xc4/0x1c2 Jun 12 14:00:44 thelibrary kernel: asm_call_irq_on_stack+0x12/0x20 Jun 12 14:00:44 thelibrary kernel: </IRQ> Jun 12 14:00:44 thelibrary kernel: do_softirq_own_stack+0x2c/0x39 Jun 12 14:00:44 thelibrary kernel: do_softirq+0x3a/0x44 Jun 12 14:00:44 thelibrary kernel: __local_bh_enable_ip+0x3b/0x43 Jun 12 14:00:44 thelibrary kernel: ip_finish_output2+0x2ec/0x31f Jun 12 14:00:44 thelibrary kernel: ? ipv4_mtu+0x3d/0x64 Jun 12 14:00:44 thelibrary kernel: __ip_queue_xmit+0x2a3/0x2df Jun 12 14:00:44 thelibrary kernel: __tcp_transmit_skb+0x845/0x8ba Jun 12 14:00:44 thelibrary kernel: tcp_connect+0x76d/0x7f4 Jun 12 14:00:44 thelibrary kernel: tcp_v4_connect+0x3fc/0x455 Jun 12 14:00:44 thelibrary kernel: __inet_stream_connect+0xd3/0x2b6 Jun 12 14:00:44 thelibrary kernel: inet_stream_connect+0x34/0x49 Jun 12 14:00:44 thelibrary kernel: __sys_connect+0x62/0x9d Jun 12 14:00:44 thelibrary kernel: ? __sys_bind+0x78/0x9f Jun 12 14:00:44 thelibrary kernel: __x64_sys_connect+0x11/0x14 Jun 12 14:00:44 thelibrary kernel: do_syscall_64+0x5d/0x6a Jun 12 14:00:44 thelibrary kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Jun 12 14:00:44 thelibrary kernel: RIP: 0033:0x146c9bdec53b Jun 12 14:00:44 thelibrary kernel: Code: 83 ec 18 89 54 24 0c 48 89 34 24 89 7c 24 08 e8 bb fa ff ff 8b 54 24 0c 48 8b 34 24 41 89 c0 8b 7c 24 08 b8 2a 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 2f 44 89 c7 89 44 24 08 e8 f1 fa ff ff 8b 44 Jun 12 14:00:44 thelibrary kernel: RSP: 002b:0000146c98416f20 EFLAGS: 00000293 ORIG_RAX: 000000000000002a Jun 12 14:00:44 thelibrary kernel: RAX: ffffffffffffffda RBX: 0000146c90d18c60 RCX: 0000146c9bdec53b Jun 12 14:00:44 thelibrary kernel: RDX: 0000000000000010 RSI: 0000146c90e4ac94 RDI: 000000000000004b Jun 12 14:00:44 thelibrary kernel: RBP: 0000146c98417160 R08: 0000000000000000 R09: 0000146c98418258 Jun 12 14:00:44 thelibrary kernel: R10: 0000146c9841710c R11: 0000000000000293 R12: 0000146c90e4ac94 Jun 12 14:00:44 thelibrary kernel: R13: 0000000000000000 R14: 0000146c98418258 R15: 0000146c90003310 Jun 12 14:00:44 thelibrary kernel: Modules linked in: nvidia_uvm(PO) xt_nat xt_tcpudp veth macvlan xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter xfs md_mod nvidia_drm(PO) nvidia_modeset(PO) drm_kms_helper drm backlight agpgart syscopyarea sysfillrect sysimgblt fb_sys_fops nvidia(PO) ip6table_filter ip6_tables iptable_filter ip_tables x_tables igb i2c_algo_bit ipmi_ssif amd64_edac_mod edac_mce_amd kvm_amd wmi_bmof kvm crct10dif_pclmul crc32_pclmul crc32c_intel mpt3sas ghash_clmulni_intel aesni_intel i2c_piix4 crypto_simd cryptd raid_class i2c_core nvme ahci scsi_transport_sas nvme_core wmi glue_helper acpi_ipmi ccp k10temp rapl libahci button ipmi_si acpi_cpufreq [last unloaded: i2c_algo_bit] Jun 12 14:00:44 thelibrary kernel: ---[ end trace 98e92523c69e7e44 ]--- Jun 12 14:00:44 thelibrary kernel: RIP: 0010:nf_nat_setup_info+0x129/0x6aa [nf_nat] Jun 12 14:00:44 thelibrary kernel: Code: ff 48 8b 15 ef 6a 00 00 89 c0 48 8d 04 c2 48 8b 10 48 85 d2 74 80 48 81 ea 98 00 00 00 48 85 d2 0f 84 70 ff ff ff 8a 44 24 46 <38> 42 46 74 09 48 8b 92 98 00 00 00 eb d9 48 8b 4a 20 48 8b 42 28 Jun 12 14:00:44 thelibrary kernel: RSP: 0018:ffffc90000338700 EFLAGS: 00010202 Jun 12 14:00:44 thelibrary kernel: RAX: ffff88818b422f06 RBX: ffff888108b21a40 RCX: 0000000000000000 Jun 12 14:00:44 thelibrary kernel: RDX: 01090000ffffff76 RSI: 000000003f50ed19 RDI: ffffc90000338720 Jun 12 14:00:44 thelibrary kernel: RBP: ffffc900003387c8 R08: 0000000098f45bae R09: ffff88813dd40620 Jun 12 14:00:44 thelibrary kernel: R10: 0000000000000348 R11: ffffffff815cbe4b R12: 0000000000000000 Jun 12 14:00:44 thelibrary kernel: R13: ffffc90000338720 R14: ffffc900003387dc R15: ffffffff8210b440 Jun 12 14:00:44 thelibrary kernel: FS: 0000146c98419700(0000) GS:ffff88881e980000(0000) knlGS:0000000000000000 Jun 12 14:00:44 thelibrary kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jun 12 14:00:44 thelibrary kernel: CR2: 0000150d3d688320 CR3: 000000020149a000 CR4: 0000000000350ee0 Jun 12 14:00:44 thelibrary kernel: Kernel panic - not syncing: Fatal exception in interrupt
    3 points
  41. sure, let me zip up and send you DM, i don't want people downloading until we get a confirmed use case.
    3 points
  42. I'm having the same issue with drives not spinning down after upgrading to 6.9 I have spin down delay set to 15 minutes, and already confirmed that with Dynamix Auto Fan Control enabled, the drives wont spin down, with it disabled, the fans spin down within 15 minutes as they should. Also confirmed that the drives will stay down if manually spun down.
    3 points
  43. I do get this also when I plugin USB Devices, Unassigned devices plugin is installed and array is spun down. There is an issue when UD tells Unraid to update and its being looked into, hopefully fix will be in next RC . Do you get the entries when connecting usb devices? See this thread
    3 points
  44. [I just spent 3 hours documenting the step by step work I'd been doing on this for logging in this thread. I have the same UPS and the same errors and the same problems. I don't use unRAID though but I'm sure it's nothing to do with unRaid. I've spent several nights attacking this problem from a low level USB /HID driver problem. Then, 5 minutes ago, I tried something different. And it fixed it. What... the... No guarantees, but here's what I did: # usb_modeswitch -v 0x051d -p 0x0003 --reset-usb (Check lsusb output to find out your vendor and product IDs) That's it. apctest works. apcaccess now reports ALL data.] Background: UPS: APC smc1500-2UC (same as the smc1500 but rack-mount. ) bios: 1.41, modbus enabled via front panel. ubuntu 20.04 apcupsd 3.14.14 apcupsd.conf: UPSCABLE usb UPSTYPE modbus DEVICE Unplug the usb cable then plug it back in. lsusb reports the device with the incremented port: root@sophie:/etc/apcupsd# lsusb Bus 001 Device 022: ID 051d:0003 American Power Conversion UPS dmesg shows: [Sun Jan 17 21:31:31 2021] usb 1-6.4: USB disconnect, device number 21 [Sun Jan 17 21:31:36 2021] usb 1-6.4: new full-speed USB device number 22 using xhci_hcd [Sun Jan 17 21:31:36 2021] usb 1-6.4: New USB device found, idVendor=051d, idProduct=0003, bcdDevice= 0.01 [Sun Jan 17 21:31:36 2021] usb 1-6.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [Sun Jan 17 21:31:36 2021] usb 1-6.4: Product: Smart-UPS_1500 FW:UPS 04.1 / ID=1018 [Sun Jan 17 21:31:36 2021] usb 1-6.4: Manufacturer: American Power Conversion [Sun Jan 17 21:31:36 2021] usb 1-6.4: SerialNumber: 3S2012X12122 [Sun Jan 17 21:31:36 2021] hid-generic 0003:051D:0003.001C: hiddev1,hidraw5: USB HID v1.11 Device [American Power Conversion Smart-UPS_1500 FW:UPS 04.1 / ID=1018] on usb-0000:00:14.0-6.4/input0 Making sure that apcupsd is not running, I can run apctest but get the following: root@sophie:/etc/apcupsd# apctest 2021-01-17 21:15:44 apctest 3.14.14 (31 May 2016) debian Checking configuration ... sharenet.type = Network & ShareUPS Disabled cable.type = USB Cable mode.type = MODBUS UPS Driver Setting up the port ... 0.837 apcupsd: ModbusUsbComm.cpp:142 ModbusRx: TIMEOUT Doing prep_device() ... 4.091 apcupsd: ModbusUsbComm.cpp:142 ModbusRx: TIMEOUT You are using a MODBUS cable type, so I'm entering MODBUS test mode Hello, this is the apcupsd Cable Test program. This part of apctest is for testing MODBUS UPSes. Getting UPS capabilities...SUCCESS Please select the function you want to perform. 1) Test kill UPS power 2) Perform self-test 3) Read last self-test result 4) View/Change battery date 5) View manufacturing date 10) Perform battery calibration 11) Test alarm Q) Quit Note that it glitches during initialisation but gets there in the end. Trying a safe function (Perform self-test) works, as does 'Read last self-test result'. However, the moment I exit apctest, the following appears in dmesg: [Sun Jan 17 21:17:27 2021] usb 1-6.4: reset full-speed USB device number 21 using xhci_hcd Ok, fine. apctest resets the device. However, if I try to re-run apctest immediately, the following occurs: root@sophie:/etc/apcupsd# apctest 2021-01-17 21:18:31 apctest 3.14.14 (31 May 2016) debian Checking configuration ... sharenet.type = Network & ShareUPS Disabled cable.type = USB Cable mode.type = MODBUS UPS Driver Setting up the port ... 0.289 apcupsd: ModbusUsbComm.cpp:258 WaitIdle: interrupt_read failed: Success 0.849 apcupsd: ModbusUsbComm.cpp:142 ModbusRx: TIMEOUT 1.402 apcupsd: ModbusUsbComm.cpp:142 ModbusRx: TIMEOUT 1.602 apcupsd: ModbusComm.cpp:201 SendAndWait: Wrong size (exp=7, rx=21) 1.674 apcupsd: ModbusComm.cpp:201 SendAndWait: Wrong size (exp=7, rx=21) 1.962 apcupsd: ModbusComm.cpp:201 SendAndWait: Wrong size (exp=21, rx=7) 2.033 apcupsd: ModbusComm.cpp:201 SendAndWait: Wrong size (exp=21, rx=7) ... followed by many, many more glitchy lines, and eventually the menu. Exiting apctest and trying to start up the apcupsd daemon causes the following to start appearing in the syslogs: [Sun Jan 17 21:19:28 2021] usb 1-6.4: reset full-speed USB device number 21 using xhci_hcd [Sun Jan 17 21:19:55 2021] usb 1-6.4: reset full-speed USB device number 21 using xhci_hcd [Sun Jan 17 21:19:57 2021] usb 1-6.4: reset full-speed USB device number 21 using xhci_hcd [Sun Jan 17 21:24:08 2021] usb 1-6.4: reset full-speed USB device number 21 using xhci_hcd [Sun Jan 17 21:25:09 2021] usb 1-6.4: reset full-speed USB device number 21 using xhci_hcd Which I assume is happening as a consequence of something "not quite right". Here's the (wrong) output of apcaccess when things aren't working: root@sophie:/etc/apcupsd# systemctl start apcupsd root@sophie:/etc/apcupsd# apcaccess APC : 001,018,0436 DATE : 2021-01-17 21:19:46 -0800 HOSTNAME : sophie VERSION : 3.14.14 (31 May 2016) debian UPSNAME : sophieUPS CABLE : USB Cable DRIVER : MODBUS UPS Driver UPSMODE : Stand Alone STARTTIME: 2021-01-17 21:19:43 -0800 STATUS : MBATTCHG : 5 Percent MINTIMEL : 3 Minutes MAXTIME : 0 Seconds NUMXFERS : 0 TONBATT : 0 Seconds CUMONBATT: 0 Seconds XOFFBATT : N/A STATFLAG : 0x05000000 END APC : 2021-01-17 21:19:46 -0800 And even when things are sort of working, here's the output of apcacess that still isn't any good: WIthout going into the 3 day jungle safari that has been my digging into learning the apcupcd code and how usb devices work when plugged into linux, suffice to say that I learned much about things I will never have a use for, but eventually worked out that I wanted to be able to disconnect and reconnect the usb device "at will", in the hopes of using the failed workaround documented by @Gnomuz. This led me through HID space and the frustrations of identifying the device path when something is plugged in. But then I discovered that 'mod_switch' has a reset parameter, and you only need to provide it with the Vendor and product IDs reported by 'lsusb'. Thus, the still-unbelievable simplicity of this: root@sophie:/etc/apcupsd# usb_modeswitch -v 0x051d -p 0x0003 --reset-usb Look for default devices ... Found devices in default mode (1) Access device 022 on bus 001 Get the current device configuration ... Current configuration number is 1 Use interface number 0 with class 3 Warning: no switching method given. See documentation Reset USB device . Device was reset -> Run lsusb to note any changes. Bye! Followed pessimistically by root@sophie:/etc/apcupsd# apctest 2021-01-17 22:38:48 apctest 3.14.14 (31 May 2016) debian Checking configuration ... sharenet.type = Network & ShareUPS Disabled cable.type = USB Cable mode.type = MODBUS UPS Driver Setting up the port ... Doing prep_device() ... You are using a MODBUS cable type, so I'm entering MODBUS test mode Hello, this is the apcupsd Cable Test program. This part of apctest is for testing MODBUS UPSes. Getting UPS capabilities...SUCCESS Please select the function you want to perform. 1) Test kill UPS power 2) Perform self-test 3) Read last self-test result 4) View/Change battery date 5) View manufacturing date 10) Perform battery calibration 11) Test alarm Q) Quit Select function number: q Where I noticed that I didn't get any of the glitch messages at all. I then repeatedly ran apctest over and over expecting errors, and got none. Anywhere. Still not believing anything, I started up apcupsd: root@sophie:/etc/apcupsd# systemctl start apcupsd and of course immediately tried the penultimate test, apcaccess. Which now reported this [you're gonna love this]: root@sophie:/etc/apcupsd# apcaccess APC : 001,038,0879 DATE : 2021-01-17 22:39:52 -0800 HOSTNAME : sophie VERSION : 3.14.14 (31 May 2016) debian UPSNAME : SophieUPS CABLE : USB Cable DRIVER : MODBUS UPS Driver UPSMODE : Stand Alone STARTTIME: 2021-01-17 22:39:45 -0800 STATUS : ONLINE LINEV : 118.4 Volts LOADPCT : 34.9 Percent LOADAPNT : 22.6 Percent BCHARGE : 98.4 Percent TIMELEFT : 28.0 Minutes MBATTCHG : 5 Percent MINTIMEL : 3 Minutes MAXTIME : 0 Seconds OUTPUTV : 118.4 Volts DWAKE : 0 Seconds DSHUTD : 180 Seconds ITEMP : 22.6 C BATTV : 26.0 Volts LINEFREQ : 60.0 Hz OUTCURNT : 2.75 Amps NUMXFERS : 0 TONBATT : 0 Seconds CUMONBATT: 0 Seconds XOFFBATT : N/A SELFTEST : OK STATFLAG : 0x05000008 MANDATE : 2020-03-17 SERIALNO : 3S2012X12122 BATTDATE : 2020-04-14 NOMOUTV : 120 Volts NOMPOWER : 900 Watts NOMAPNT : 1440 VA FIRMWARE : UPS 04.1 / 00.5 END APC : 2021-01-17 22:40:46 -0800 It's all there, and more. My current best guess is that something isn't being initialized properly, or reset properly, within the apcupsd / apctest code. But running usb_modeswitch resets it properly/fully. That'll do me.
    3 points
  45. Ok, I've fixed this for me. Running a strace on the net ads join command it was referencing /var/cache/samba/smb_krb5/krb5.conf.SHORTDOMAIN in which there is the line include /etc/krb5.conf That file doesn't exist on my system, instead I have /etc/krb.conf. A symlink later and I can join the domain properly. I'm adding this to /boot/config/go for now # Fix missing /etc/krb5.conf if [ ! -f /etc/krb5.conf ] && [ -f /etc/krb.conf ]; then ln -s /etc/krb.conf /etc/krb5.conf fi
    3 points
  46. If you don't see device temperatures upon reboot, just click "spin up all" and everything should be fine until I can release -rc3.
    3 points
  47. Prior to RC1, UD set a timer in each disk that would spin the disk down after 15 minutes. This was not that reliable because some disks would not respect it. With RC1, Unraid has taken over disk spin up/down control. RC1 only has manual spin up/down by clicking on the disk status ball. RC2 will have spin down control of UD devices so disks will spin down after inactivity. The only risk is that the UD webpage and the Dashboard will not show the correct running status.
    3 points