pervin_1

Members
  • Posts

    66
  • Joined

  • Last visited

Everything posted by pervin_1

  1. Thank you @Mainfrezzer. The upgrade to 6.12.6 went smooth, and the RAM-DISK is working perfectly. I appreciate the effort!
  2. I went ahead and left the checksums from @Mainfrezzer's script unchanged. Its weird that I initially changed the checksums with my own, and the script aborted itself and threw the error code from @Mainfrezzer's original checksum codes, IDK why. Everything it seems to be working now. I still get about ~5Gb writen per day. But without the script, its about 32Gb daily. There are still uncessary writes, but I am very happy. My two cache drives are Pro 980 Samsung 1Tb models, and they are supposed to last about 600TBW. Which means about 300 years lol. Thank you! Thank you!
  3. I am on the 12.4, and updated the compatibility code with my own checksums, and it got aborted upon the boot Error: RAM-Disk Mod found incompatible files: 45361157ef841f9a32a984b056da0564 /etc/rc.d/rc.docker 9f0269a6ca4cf551ef7125b85d7fd4e0 /usr/local/emhttp/plugins/dynamix/scripts/monitor
  4. It’s the same version. I did run without the compatibility check, and everything is working from what I see. The RAM disk shows is created in the logs. But I am gonna update it and run again. I remember we used to change the settings for each docker and added additional parameters. It sounds like is no longer the case with the updated script?
  5. Ran two md5sum checks on rc.docker and scripts monitor, the checksums are different. Which means I should change the compatibility code, correct? Thank you!
  6. Wondering if anyone can help me with questions above? Thanks!
  7. I am on 6.12.4, going to try this script. Was on 6.9.x and the old script worked great. With this new script, do I still need to edit the Paraments on my Dockers individually and extra line of code @mgutt @Mainfrezzer? BTW, how do you get the checksum for this script? I see two unique checksum codes. Thank you!
  8. lol you were right about the PostgreSQL database. Messed up my OnlyOffice docker. Had to rebuild it, was not a big deal. Got it rebuilt even better. I was testing a lot of lately, to the point where I corrupted my Nextcloud MaridDb container and decided to get rid off my Nextcloud and related containers foor good. I wasn't utilizing it's features to justify the time and effort spent maintaining it. Besides, I heavily rely on Google Drive anyway ( I do back up my stuff from G Drive regardless ). Yes, I am also going to mount /tmp to the Ram Disk inside of the containers where is safe.. My understanding containers are not aware that /tmp is not real "Ram Disk". So the writes go to SSD instead. I appreciate the hard work and input! Thank you!
  9. The scripts you shared are working perfectly. TBH, my writes ( I have been monitoring for a good time now ) are not excessive. The first script is barely showing any activiy for my containers. I see some repepetive logs for json files from /docker/containers. But I am assuming this is a RAMDISK for status and logs. Correct me if I am wrong, please. Another question, the appdata is located on my NVMe SSD cache pool. My understanding there will be some kind of writes from dockers regardless, correct? Besides that I left the script to dump the log/status files for safety reason every 30 minutes. BTW, I can see that my writes are basically coming from the OnlyOffice Document server docker ( and some from Nextcloud ). It's connected to my Nextcloud server as a document editor. I am not sure if you are familiar or using it. Edit: Nextcloud was in the tmp folder. Added extra parameter to mount the tmp folder in RAM disk ( not sure if you script handles the tmp in docker containers ). The OnlyOffice, mainly writes go to /run/postgresql every one minute or so. I am assuming is some kind of database system. Do you think it's a good idea to mount it to the RAM disk under the extra parameters?
  10. @mgutt I went ahead and implemented the changes by following the instructions, all went smoothly so far. My cache drives are 2x NVMe A-Data SX8200. I did not change the docker log file size, it wasn't necessary. I double-checked to make sure that your script worked by checking the RAM-disk size and the code itself in different locations as you have explained, all good. I do see 0.00 B/s, but the writes jump up&down ( averages about 200 Kb./s ). Is it normal? Does it mean I have some other dockers in the appfolder writing something ( besides status and log files ) to my cash drives, like Nextcloud, Plex? Thank you!
  11. Excellent and detailed guide, thank you very much! I pretty much completed the first two steps. But did not want to gamble with the third step since I do have sensitive data with the rest of the containers. Not that the 3rd step is hard to follow, but as you mentioned, you don't want to implement these steps with sensitive information like database, Nextcloud and etc. My basic calculation show that my two NVME Adata drives had in average 180-192GB of random writes daily staring from 2018-2019. Glad randomly decided to read this topic delivered to my email box lol. Noneless, always make sure to have a backup. I made some mistakes, experienced some problems with my appdata folder with the "mover" function. Made a few important dockers unusable. Restored the dockers from the backup, boom - ready to Rock & Roll! Again, I appreciate the effort and all time taken to write this guide! You are awesome!
  12. No solution tbh. I am stuck perhaps. We are going to figure this out, eventually. Let me know if you come up with any news or a solution. Would appreciate it!
  13. I also received this message the first time when I tried to TRIM the NVMe drive ( ADATA SX8200 480GB, relatively new SSD) connected directly to the MOBO's M.2 port — using as a cache drive. I upgraded to the latest 6.7 Stable a few days ago, never seen this message before. Diagnostics attached. Thank you! tower-diagnostics-20190609-2320.zip
  14. Anybody have any idea why DuckDNS docker works 99% of times, it always succeeds updating my IP address, but when my internet goes down ( IP change overnight ), it fails to update my address with the usual message something went wrong please check your settings. The only to fix it is to restart the docker; then it works again. I would appreciate any help. Thank you in advance!
  15. Does anybody have any idea why I am getting this message after upgrading MariaDB 10.3.15 today? Was running Nextcloud 15. Updated to the latest Nextcloud 16, the same error "Error occurred while checking server setup" is still persisting. edit: It had nothing to do with my setup or Maria DB. Checked the logs after, it turns out the Nextcloud.com was down. And that was causing the issues. Because part of the security scan is an online connection to their servers. All good Now!
  16. follow up to my own post: this is the most relevant information I came across today, cannot guarantee its gonna work, but gave it a try, fingers crossed, will post results shortly. Apparently, my problem started back in July, not in Oct. as I stated in the above. link Also, you can try to disable the NIC flow control and NIC offload using the plugin tips and tricks to ensure persistence after reboots, otherwise use ethtool and user scripts to make it persistent.
  17. Oct 13 12:19:25 Tower kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang: Oct 13 12:19:25 Tower kernel: TDH <0> Oct 13 12:19:25 Tower kernel: TDT <8> Oct 13 12:19:25 Tower kernel: next_to_use <8> Oct 13 12:19:25 Tower kernel: next_to_clean <0> Oct 13 12:19:25 Tower kernel: buffer_info[next_to_clean]: Oct 13 12:19:25 Tower kernel: time_stamp <127739b72> Oct 13 12:19:25 Tower kernel: next_to_watch <0> Oct 13 12:19:25 Tower kernel: jiffies <12773aa80> Oct 13 12:19:25 Tower kernel: next_to_watch.status <0> Oct 13 12:19:25 Tower kernel: MAC Status <80083> Oct 13 12:19:25 Tower kernel: PHY Status <796d> Oct 13 12:19:25 Tower kernel: PHY 1000BASE-T Status <3c00> Oct 13 12:19:25 Tower kernel: PHY Extended Status <3000> Oct 13 12:19:25 Tower kernel: PCI Status <10> Oct 13 12:19:27 Tower dhcpcd[1696]: br0: probing for an IPv4LL address I have been getting this error since Oct. 5th-6th and it was apparently unnoticed until today when my server became unresponsive, no GUI or SSH access, ethernet interface was down? Maybe, here is the picture of the monitor with the above message: Had to use a monitor to see what's happening, so far so good, Dockers and VMs were running just fine along with other services. But the above problem caught my eyes, thinking it's related. Diag. zip file is attached to this post down below. Thanks in advance!!1 tower-diagnostics-20181013-1219.zip edit: checked the syslog going back to July 2018 and it turns it started back then.
  18. did the instructions, check it down below link
  19. done, check the post down below and pass on the information if you could to help others!!!! link
  20. How to setup collabora online with Nextcloud behind reverse proxy, 3 steps: -Letsencrypt nginx conf file -Collabora docker configuration -Installing collabora app under admin account in nextcloud web page The key is to use another domain name for the collabora docker and nginx conf file. Meaning, if you have used cloud.* in letsencrypt nextcloud.subdomain.conf, then you gonna have to use office.* in you server directive of the collabora.subdomain.conf. ----First, let's create the collabora.subdomain.conf file in /mnt/user/appdata/letsencrypt/nginx/proxy-confs (assuming you are using the Unraid UI terminal and linuxserver letsencrypt docker). Put this code in above-created conf file: upstream collada-office { server your_local_unraid_server_adresss:9980; } server { listen 443 ssl; server_name office.example.com; include /config/nginx/ssl.conf; # static files location ^~ /loleaflet { proxy_pass https://collada-office; proxy_set_header Host $host; } # WOPI discovery URL location ^~ /hosting/discovery { proxy_pass https://collada-office; proxy_set_header Host $host; } # Main websocket location ~ /lool/(.*)/ws$ { proxy_pass https://collada-office; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; proxy_set_header Host $host; proxy_read_timeout 36000s; } # Admin Console websocket location ^~ /lool/adminws { proxy_buffering off; proxy_pass https://collada-office; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; proxy_set_header Host $host; proxy_read_timeout 36000s; } # download, presentation and image upload location ~ /lool { proxy_pass https://collada-office; proxy_set_header Host $host; } } ---Second, Go to your Unraid docker tab and edit the collaroba docker and make sure it looks like in the screenshot: ---Third, Install the collabora app under the admin account in Nextcloud account and use this down below: Restart all 3 dockers, NextCloud , Letsecncrypt, and Collabora_Online, everything should be up and running. BTW office.example.com should be also pointing to your home server, just like nextcloud.example.com domain. Good luck!!!!
  21. Sorry was away for a while, I see that you replied to my comment back in Sep. If you are interested, I am willing to write a tutorial with instructions and commands get it to work. PM me please and I will post the instructions here, it's kinda long
  22. Had the same problem after doing a reverse proxy setup, had to tweak some settings here and there. Are you using Collabora docker like me?
  23. Have you found the solution yet? I checked this link to get an idea how to fix it, but I got confused even more at this link
  24. Hey, thank you for the instructions. I am also trying to setup Nextcloud with a reverse proxy in conjunction with Letsencrypt, everything works, except the Collabora. Can you share your settings, please? So confused. Thanks!!!