bobokun

Members
  • Posts

    225
  • Joined

  • Last visited

Posts posted by bobokun

  1. 2 hours ago, tazire said:

    im getting this

     

    The "X-Frame-Options" HTTP header is not set to "SAMEORIGIN". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.

     

    Even with the settings included in the new config file. And strangely when i F12 in chrome on my nextcloud tab it appears to be set to SAMEORIGIN... 

     

    default 5.93 kB · 1 download

    comment out the line 38 with #

    • Like 1
  2. 1 hour ago, almulder said:

    LOL yep that was it, that's what I get for copying and pasting from the nextcloud site, they have it with a $ bold note section, but without it in the file section. Thanks!

     

    Also it seem to run twice as fast not with the changes. not instead of 10-20 seconds delay when switching screens it like only 5 or less. :)

    Did you have you change anything in your appdata\nginx\site-confs\default or was it just from appdata\nextcloud\site-confs\default? I tried to follow the config as well and this is what I tried changing it to but it doesn't seem to be working. Can you see if I did anything wrong?

     

    Old Config:

    location / {
    
        rewrite ^/remote/(.*) /remote.php last;
    
        rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;
    
        try_files $uri $uri/ =404;
      }
    
      location ~ \.php(?:$|/) {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        include /etc/nginx/fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param HTTPS on;
        fastcgi_param modHeadersAvailable true; #Avoid sending the security headers twice
        fastcgi_pass php-handler;
        fastcgi_intercept_errors on;
      }

    New Config:

    location / {
    
         rewrite ^ /index.php;
      }
    
      location ~ ^\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+)\.php(?:$|\/) {
        fastcgi_split_path_info ^(.+?\.php)(\/.*|)$;
        try_files $fastcgi_script_name =404;
        include /etc/nginx/fastcgi_params;
        fastcgi_param SCRIPTFILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATHINFO $fastcgi_path_info;
        fastcgi_param HTTPS on;
        # Avoid sending the security headers twice
        fastcgi_param modHeadersAvailable true;
       # Enable pretty urls
        fastcgi_param front_controller_active true;
        fastcgi_pass php-handler;
        fastcgi_intercept_errors on;
        fastcgi_request_buffering off;
      }

     

    • Like 1
  3. I hope this it the right thread to ask but I've been trying to create a script to change the throttle speeds of my upload. Does anyone have any experience with this? Right now after some investigating the only way I managed to get this to work is to change the lines for download_rate and upload_rate in rtorrent.rc and restarting the docker container. The end goal is when people are streaming remotely on my plex server I want it to dynamically adjust the upload rate in my rutorrent and adjust it back when nobody is streaming on my plex server. I've tried to follow this guide to adjust it through the throttle.php plugin but it doesn't seem to change in the WebUI. https://www.seedhost.eu/whmcs/knowledgebase/245/rTorrentorruTorrent-limit-uploadordownload-speed.html

  4. When adding a drive to Unraid it clears the drive before adding it to the array. I'm seeing a few Buffer I/O Errors in the log while it is clearing. Is it still safe to add to the array? Prior to adding this drive I did a SMART extended self-test that resulted in no errors.

     

    Example errors:

    Oct  3 07:19:11 unNAS kernel: Buffer I/O error on dev md5, logical block 0, async page read
    Oct  3 07:19:13 unNAS kernel: Buffer I/O error on dev md5, logical block 1953506608, async page read

     

    Please see attached diagnostics. Thank you!

    unnas-diagnostics-20191003-2315.zip

  5. 13 hours ago, jbartlett said:

    That's correct, my utility only does non-destructive reads. If you want to identify if Disk 4 has issues and remove the Parity drive from the equation, carefully recreate your array without Disk 4. The parity rebuild speeds will tell you if the Parity drive is the issue. If it looks good, mount the old Drive 4 using the UD plugin and copy files to it to see if you can duplicate the slow writes.

     

    While the Parity is rebuilding, you can also kick off a long SMART test on the old Drive 4. If everything still looks good, take the array offline and kick off a long SMART test on the parity drive and all of the others for a shiz-n-grins sanity check.

    I did as you suggested and I created a new config, removed both Disk4 and the old Parity drive to rule out all bad options. I put the new parity drive in that has successfully passed preclear at 180-200MB/S. Now when I start the array and it is rebuilding the parity it's extremely slow! I don't think it's the drives anymore because the new parity drive was precleared super fast. Do you think it could be my SAS HBA card? I have the Dell PERC H310. If it's not that then it might be the miniSAS to sata cables that I'm using. Either way now I'm at a loss once again what I should do. I purchased some new miniSAS-Sata cables and hopefully that helps.

     

    image.thumb.png.0ff8758f3d94db6c093a8638b8df9ac2.png

     

     

    EDIT: I powered off my machine and decided to use just normal SATA cables for all 5 drives instead of using the HBA card. So now all my drives are plugged in using SATA cables to my motherboard. Parity drive starts rebuilding started off slow at 19MB/s-30MB/s but after couple minutes it ramped up to 126MB/s. 

     

    I just realized my HBA card is plugged into a PCIE 3.0 X4 (In x8) slot. I'm not sure if I need to plug it into a PCIE 3.0 x8 slot would that help?

  6. 3 minutes ago, jbartlett said:

    That ... that is weird. I've never seen anything like that. Even if every other drive was being pounded at the same time, you wouldn't see something like this.

     

    Your Tunable's won't affect it because it doesn't go through the unraid driver to access, it's a straight dd read using a block size given by the drive as being the optimal size.

     

    The drive might not be bad. The only thing I can think of is to try pinning some CPU's to the docker to see if it cleans it up if it happens again. I'm also assuming that you didn't have any CPU intensive tasks going on or no VM's taking all the CPU's away.

    I don't think it's the DispSpeed utility that is incorrect because the past few months my parity checks have been extremely slow (fluctuating between 3.5MB/s to 50MB/s) and now when I try to do a parity check it runs at 150-200MB/s full speed with no fluctuation. Should I still replace the parity just in case? I think the read speeds are fine but write speeds still seem to be slow because when copying from cache drive to disk4 it is writing at 30MB/s. From my understanding DiskSpeed doens't test for write speeds only read.

  7. I'm hoping some of you guys might have some insight on what is going on. So I ran the DiskSpeed test multiple times on all my drives but constantly it showed my Parity and Disk4 was very slow. This caused my parity checks to double in length the past few months because it would slow down to 3.5MB/S for hours and then ramp back up to 150MB/S. I figured I would need to replace both the Parity and Disk4. I started to preclear a new 10TB drive that I was planning on replacing my parity with and move all the contents from disk4 to disk5 so I can shrink the array. After waiting a couple days to move everything from disk4 to disk5 (remember it fluctuates from 3.5MB/s to 50MB/s max.. even with turbo write on), I finally have Disk4 empty. Before I send it back for RMA I decide to do a diskSpeed test one last time...shockingly all my drives are now running at full speed and I'm not even sure if I need to replace my Parity or disk4 anymore...Does anyone know the reasons why this might be the case? I'm afraid that it could be because Disk4 is currently empty and once Disk4 is no longer empty it will start to slow down dramatically again.

     

    The differences I can only think of is (I ran DiskSpeed without any other docker containers running.) I thought this could be the reason so I started up all my docker containers and re-ran the tests. It still ran at full speed. 

     

    Another change I did was change the tunables in Disk settings from 

    Tunable (md_num_stripes): 1xxx  to

    Tunable (md_num_stripes): 8192

     

    Here are the results for Disk4 and Parity.

    Disk4:

    image.png.d0092ccd6492a7e612eda8f75c29f91d.png

     

    Parity:

    image.png.966d60ae35e0b26b148c8148441d7b76.png

     

     

     

  8. On 9/25/2019 at 2:25 PM, bonienl said:

    The plex errors come from the wrong crypto library installed.

     

    Remove the DevPack plugin, it installs the wrong version.

     

    I'm still receiving the same errors after uninstalling devpack plugin. I tried restarting Plex container but that doesn't help. Is there anything else I need to do to get the right crypto library install?

  9. Okay I suspect that there could be a virus on my parents PC that could be trying to connect to my unraid server. Any idea about the plex related errors? Is that also connected?

     

    Sep 25 13:28:31 unNAS kernel: traps: Plex Media Scan[21984] general protection ip:15421f94d097 sp:154213c38fe0 error:0 in libcrypto.so.1.0.0[15421f83c000+204000]

  10. 10.0.0.10 is the internal ip address of my unraid server.

     

    10.0.0.21 is my parent's PC. They are not tech savvy at all and I doubt they would know how to connect or try to connect to the server. I asked them if they were using the PC at 13:17 and they were but they were just transferring files through SMB fileshare to my unraid server that I had already saved credentials for. I asked if they had tried to enter in any username/passwords but they denied anything.