• Posts

  • Joined

  • Days Won


Everything posted by BRiT

  1. Setup for "newperms ." misbehavior, here are the raw command to duplicate this from a root command prompt: cd /mnt/cache mkdir tmp cd tmp touch testfile.txt ls -al . ls -al /usr/local/emhttp/plugins/dynamix/scripts/ newperms . ls -al /usr/local/emhttp/plugins/dynamix/scripts/ ls -al . Setup: Execution: Examination of the bad behavior:
  2. Try it as shown in the previous screen attachment and you will see that when passing in "." instead of using the current directory the user is in, it for some reason interprets it to mean the current location of the script which is /usr/local/emhttp/plugins/dynamix/scripts/ It used to work perfectly before whenever these changes were done. Do you need me to attach another screenshot to show how to reproduce the bad behavior?
  3. I figured out some of my grief was caused by using "newperms ." at the command prompt, that should set new permissions for the current working directory, which I normally had always done when managing media content with unraid 6.8.3 or earlier. Issuing that command instead completely clobbers the permissions of several scripts at /usr/local/emhttp/plugins/dynamix/scripts/ instead, which leads to all sorts of bad behavior from the UI.
  4. I didn't notice this until today, but has the syntax to "newperms" script changed after unRaid 6.8.3 ? I used to always use "newperms ." to change the permissions on the current directory I'm in. Doing so on 6.10.3 results in the permissions of /usr/local/emhttp/plugins/dynamix/scripts/ changing instead. This breaks things.
  5. Mine spin down fine. I know that doesn't help you, but know that it does work.
  6. Updated yesterday and so far so good. The system came up after reboot without issues.
  7. Can you provide more specifications as to what you define as mobile? What size screen? What browser? For the most part I find the current UI usable on my Android Tablet with Chrome browser, but I know that my tablet has better screen resolution than what most users are likely using.
  8. Pretty sure all those ini files are in RAM if they're under /usr/local/emhttp, unless they're linked back to /boot/ or elsewhere that is on the flash drive?
  9. No meaningful difference between the two lists. If you have time and are in a troubleshooting mood, you could see if anything happens after running CA Backup before it's next scheduled time. If you see similar or odd behavior, at an open shell, type "sync" before you try troubleshooting again and then see what's what.
  10. Well I can't think of other commands to run to troubleshoot things as to the cause or what really happened. I was hoping someone else would jump in with ideas to run. If you want to resolve the situation now, you can reboot the system. However, that will prevent additional troubleshooting steps, but I think to trigger it you might only have to run CA Backup. If you do reboot now, comparing the earlier posted emHttp.txt file to one generated after the reboot and you verify the system is functional again might be interesting to see what exactly disappeared.
  11. There's also log files from the CA Backup process located in /var/lib/docker/unraid/ca.backup2.datastore/appdata_backup.log or /tmp/ca.backup2/tempFiles/ that you should look at to see if you can find anything in there. I see a line in the syslog that was at the end run of CA Backup at 03:46:10, not sure if that's normal to have it echoed in the syslog.
  12. It's very bizarre that those ini files would not be there as they are part of every running system, and what you described is very close to what I and another experienced after CA Backup ran. Have a deeper look inside there, like can you look at a recursive listing [ find /usr/local/emhttp -print ] to get a manifest of what is or isn't there? It will prob be pretty big so might need to redirect output to a file.
  13. The Last time I ran CA Backup on a 6.10.x system I had system errors, it looked like certain in-memory directories were entirely wiped out. It couldn't find the "newperms" script which is built in and almost nothing in the UI worked as it couldn't find any of the files. When I looked at UI Plugins it could not determine the version of anything. I think that was because somehow entire directories or mountpoints somehow got wiped out or reset. I think you might be in the same state, so see what if anything exists in /usr/ and /usr/local/emhttp/.
  14. I think you might have been hit by a possibly issue with CA Backup plugin. maybe @Squid has an idea about what you can try and do to help them troubleshoot the issue? I say this because from your snippet it looked like errors happened after CA Backup Plugin ran. At the very least post your sylslog to your NEXT post. Ideally for troubleshooting what is desired is your Diagnostics zip file to your next post by typing in "diagnosics" at the terminal widow. But I think you might have issues with that as the command might not be found, which is why I mentioned at least the syslog file. If you can't get the file now, try to copy it to a drive in cache or array before rebooting. Also before rebooting try looking around at the fiesystems of /usr/ or other standard locations to see if files are still there or seem to be missing from the system in memory. Edit: I see you were able to post diagnostics. But still have a look around the various standard locations of the OS and see what's there and what isnt.
  15. Have you tried using IPVLAN mode instead of macvlan?
  16. Like you, I had USB and VirtXMl backups configured too. I had the backup set as weekly Monday. So it was this morning when it ran. I think this was the first time it would have kicked off when I was on something newer than 6.8.3. I upgraded to 6.10 after a bit and then to 6.10.2 but did not really use the system between those updates and reboots to know if it was in a troubled situation. I should have grabbed more logs and done more research, but I didn't have time and hoped for quick reboot to resolve the condition. Here's the backup directory showing it ran: For now, I no longer have the plugin installed. I'm not doing docker development on the system anymore so don't need appdata to be backed up as frequently, and using the backup from this morning will suffice for a while.
  17. I had something similar happen with 6.10.2 where Community Applications could not detect if installed Plugins were new or current. The last popup message on the UI was about "CA Appdata Backup" running and finishing. I also had a command window open at the time and could not issue a "newperms" command. It said command not found. A quick reboot and everything is working as it should. I did not spend much time investigating things and sadly did not keep the syslog. I did not see anything obviously wrong from a quick DF before the reboot.
  18. I think there is a logical issue with your script. There are duplicate case statements [ button/power ]. Only the first one will be executed. I think you need to adjust your script so your customization is combined into the first case statement. Maybe something more like this: #!/bin/sh # Default acpi script that takes an entry for all actions IFS=${IFS}/ set $@ case "$1" in button/power) case "$2" in PBTN) . /boot/config/plugins/user.scripts/scripts/VMStartStop/script ;; LNXPWRBN:00) . /boot/config/plugins/user.scripts/scripts/VMStartStop/script ;; *) logger "ACPI action $2 is not defined" ;; esac ;; *) # logger "ACPI group $1 / action $2 is not defined" ;; esac
  19. It would be extra complicated because the percentages would take longer and longer to run as the disks get slower. The time duration to do the last 25% will be substantially longer than the first 25%. As you said, the best bet to complete in 4 days is adjust the time ranges.
  20. Parity is indeed calculated and written in real time. It's simple for even novice users to see that in the UI dashboard by writing a file directly to a share in the array (bypassing cache drives and the need for mover) and notice how the WRITE COUNTS on the Parity Disk also increase. Parity Check, with the keyword being CHECK. That is a different thing entirely than the real-time parity protection that is indeed offered by unRaid.
  21. If you're already on an identified hardware setup and on 6.10 or 6.10.1 you're already in a possible data loss situation. The data loss is not tied to 6.10.2 upgrade.
  22. Updated to 6.10.2 without any issues whatsoever. Then again my system is not impacted by the TG3 NIC causing data corruption with VT-D enabled.
  23. I migrated over to ZohoMail a few months ago. I plan on staying there despite Google continuing their free offers. Zoho's Free offering allows for upto 5 accounts. You can still send emails via SMTP. The only possible downside is the free accounts do not offer imap/pop3 services. However their Android App for mail is pretty solid and not much different from the GMAIL app. The setup guide and migration guide were easy to follow and documented everything that had to be done. The pay tiers are pretty reasonable too, plans from $1 User/Month to $4 User/Month for Mail. They also have a workplace plan that includes online apps like word processing and spreadsheets.
  24. Updated my server from 6.8.3 to 6.10.1. No issues that weren't of my own making. I had an old version of PuTTY installed on the computer I was accessing the server from, so SSH would not connect because of Cipher selections. A quick update of Putty resolved that. I stopped docker to alter set IPVLAN. The dockers would not start with some old parameters still around from before. A quick adjustment to the extra parameters to remove the "--mac-address=" resolved that. I then updated all plugins to get versions tailored for 6.10.x series and had NERD Utils update the packages. I can't think of any additional steps I need to do at this time. Will update further should anything change.
  25. They should be Slackware packaged builds, like what NERD utils typically uses, that can be used with "installpkg" / "upgradepkg" commands.