ptr78

Members
  • Posts

    30
  • Joined

  • Last visited

Posts posted by ptr78

  1. On 1/6/2023 at 6:13 PM, binhex said:

    have a look at NAME_SERVERS, lots of people have had issues with name resolution, link to comment on delugevpn support thread but its the same code as qbittorrentvpn:-

    ...

    for more detailed comment:-

    ...

    also mention of fixing privoxy by resetting config, so delete /config/privoxy and restart container.

     

    On 1/6/2023 at 9:51 PM, ptr78 said:

    This worked, thank you!!

     

    Regarding DNS-definition found this from AirVPN Specs (https://airvpn.org/specs/ )

    Quote
    • VPN DNS addresses (private addresses, only reachable from inside the VPN): 10.4.0.1 / fde6:7a:7d20:4::1 - reachable from any virtual subnet
      However, we recommend that your machine accepts the DNS push from our servers. If that's not possible, then we suggest to set the DNS IP address matching the VPN gateway IP address, as this is the safest method to prevent certain attacks based on hijacking.

     

    So, would it be possible to implement a feature which replaces an original DNS server definition in /etc/resolv.conf after the OpenVPN client has started successfully? That is, first using for example 1.1.1.1 when connecting to a VPN server and after the connection has been made successfully replace DNS server definitions with another definitions (here 10.4.0.1). Even better would be if the new DNS server definition could be dynamically set as  the ip address returned by getvpnextip.sh.

  2. On 1/2/2023 at 12:05 AM, davbay1 said:

    Yep PIA. Same, works without proxy enabled but would prefer to have it working. 

     

    I'm using AirVPN and have the same issue. I'm still on 4.3.9-2-01 and for few weeks on Unraid 6.11.5. Torrents load OK, only the traffic via the proxy doesn't work as it should.

    Did you find any solution other than not using the proxy? @binhex, is this something you have heard before?

  3. On 11/7/2022 at 3:59 AM, wgstarks said:

    Right click and choose "set location".

     

    OK, good, thank you! I was wondering that after setting the location, will qbittorrent move files to the default save directory after a file download has been completed.

     

    Are you or anyone else having the issue of empty status info / tabs?

  4. 3 minutes ago, wgstarks said:

    Those issues were fairly common with early 4.4 versions. I was always able to restore the correct settings though. The empty info may be new though.

     

    First of all, thank you for a very fast response!

     

    Do you know how can I return the incomplete torrents to their correct directory?

     

  5. Hi, I did an update from 4.3.9-2-01 to 4.4.5-2-02 and had the following issues

    • The settings were reset default values.
    • Unfinished download were moved from incomplete torrents directory to the default save path. How can this be corrected?
    • I noticed that the "status tabs" (i.e., General, Trackers, Peers, HTTP Sources and Content) remain empty for all the torrents. In 4.3.9 this showed torrent related info normally.

    Has anybody else had these issues with any 4.4.x version of the software? Thank you for any help!

     

  6. I have experiencing very slow Unraid WebGUI speeds lately. I checked the log and there are these two lines recurring:

     

    Oct 27 08:54:51 Tower nginx: 2020/10/27 08:54:51 [crit] 5843#5843: *1992 connect() to unix:/var/tmp/qBittorrentVPN.sock failed (2: No such file or directory) while connecting to upstream, client: 192.168.XXX.YYY, server: , request: "GET /dockerterminal/qBittorrentVPN/token HTTP/1.1", upstream: "http://unix:/var/tmp/qBittorrentVPN.sock:/token", host: "tower", referrer: "http://tower/dockerterminal/qBittorrentVPN/"
    Oct 27 08:54:51 Tower nginx: 2020/10/27 08:54:51 [crit] 5843#5843: *2050 connect() to unix:/var/tmp/qBittorrentVPN.sock failed (2: No such file or directory) while connecting to upstream, client: 192.168.XXX.YYY, server: , request: "GET /dockerterminal/qBittorrentVPN/ws HTTP/1.1", upstream: "http://unix:/var/tmp/qBittorrentVPN.sock:/ws", host: "tower"

     

    I also got the following notification email form the unraid server:

    The email title: cron for user root /usr/bin/run-parts /etc/cron.daily 1> /dev/null
    The email contents: error: error setting owner of /var/log/nginx/error.log to uid 0 and gid 0: Operation not permitted

     

    I have not changed the docker config for at least 6 months. Any ideas what might cause this? All help truly appreciated.

  7. 9 hours ago, Kopernikus said:

    Would it be hard to also include Wireguard support for "custom" VPN providers?

    Did a test this morning with my VPN provider with OpenVPN got 250Mbps with Wireguard got 790Mbps.

    So the upgrade would be great and port forwarding is also supported and working (at least with TorGuard).

     

    Thx!

    Good comments from AirVPN providers regarding wireguard: https://airvpn.org/forums/topic/24292-wireguard/?tab=comments#comment-104315

  8. Hi,

    I have a wireguard remote tunneled access up and running and it works beautifully. However, how can I configure the wireguard client so that it would not use the tunnel for local addressed (192.168.1.0/24)? I thought that it would have been discussed already but I didn't find it. So, is there a way to exclude the local packets to be sent to the tunnel? The client is Windows10 computer.

    Any help very much appreciated, thank you!

     

    >>>

     

    Found a solution (kind of) with more googling. Seems that it is a Wireguard Windows client issue.

    https://williamjshipman.wordpress.com/2019/12/31/wireguard-vpn-on-windows/

     

  9. On 1/30/2020 at 2:29 PM, dlandon said:

    ...

    • Add a 'Pass Through' switch.  Set this switch to on for any disks you are passing through to a VM or Docker.  When this switch is set, UD will not allow a manual mount and will not attempt to auto mount the disk even if 'Auto Mount' is turned on.  UD will not monitor the disk temperature.

    Anyone passing through a disk to a VM or Docker should go to UD and set the 'Pass Through' switch on.  With this switch set on, UD will not allow mounting the disk.  It is known that mounting a passed through disk with UD will corrupt the file system on the disk.

    A newbie question. What is meant by pass through here? That is, I have a disk mounted by UD and it is used by few dockers via path "/mnt/disks/.." Is there an issue or can I continue using it like this? I have not enabled the pass through for the disk in UD.

  10. Here is the latest one:

    Nov 20 23:30:46 Tower kernel: sd 9:0:1:0: [sdi] tag#1 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00
    Nov 20 23:30:46 Tower kernel: sd 9:0:1:0: [sdi] tag#1 CDB: opcode=0x28 28 00 5c 09 48 98 00 00 08 00
    Nov 20 23:30:46 Tower kernel: print_req_error: I/O error, dev sdi, sector 1544112280
    Nov 20 23:30:46 Tower kernel: sd 9:0:1:0: [sdi] tag#2 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
    Nov 20 23:30:46 Tower kernel: sd 9:0:1:0: [sdi] tag#2 Sense Key : 0x2 [current] 
    Nov 20 23:30:46 Tower kernel: sd 9:0:1:0: [sdi] tag#2 ASC=0x4 ASCQ=0x2 
    Nov 20 23:30:46 Tower kernel: sd 9:0:1:0: [sdi] tag#2 CDB: opcode=0x28 28 00 62 08 d8 e0 00 00 60 00
    Nov 20 23:30:46 Tower kernel: print_req_error: I/O error, dev sdi, sector 1644746976

    This is the first one from Oct 20:

    Oct 20 14:33:43 Tower kernel: sd 9:0:1:0: [sdi] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00
    Oct 20 14:33:43 Tower kernel: sd 9:0:1:0: [sdi] tag#0 CDB: opcode=0x28 28 00 00 01 bf a8 00 00 08 00
    Oct 20 14:33:43 Tower kernel: print_req_error: I/O error, dev sdi, sector 114600

     

  11. 34 minutes ago, johnnie.black said:

    It was a disk problem (UNC @ LBA), these errors can sometimes be intermittent but are never a good sign, you can run an extended SMART test and if OK keep monitoring the disk, if it fails the disk needs replacing.

    Thank you for the very fast reply. I'll do that.

     

    Actually, I examined the syslog and saw something else also. A lot of this kind of rows: "Nov 20 23:30:46 Tower kernel: print_req_error: I/O error, dev sdi, sector 1644746976". There are about 60 of them from the last 40 days of operation. Often there are 3-5 from the same day and then several days nothing. The disk is an old one and I use it only for temporary storage purposes, so I can just change it if it fails. But what does those errors mean? That is, is it possible that some data corruption has happened or do those lines mean that a write has failed and the OS has retried and succeeded?

  12. Hi,

     

    Got a notification that stated that: "Array has 1 disk with read errors". This happened during a parity check.

     

    From the diagnostics.

    Syslog entries from the time that the errors happened:

    Nov 21 15:14:47 Tower kernel: sd 9:0:0:0: [sdh] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
    Nov 21 15:14:47 Tower kernel: sd 9:0:0:0: [sdh] tag#0 Sense Key : 0x3 [current] [descriptor] 
    Nov 21 15:14:47 Tower kernel: sd 9:0:0:0: [sdh] tag#0 ASC=0x11 ASCQ=0x0 
    Nov 21 15:14:47 Tower kernel: sd 9:0:0:0: [sdh] tag#0 CDB: opcode=0x88 88 00 00 00 00 01 3c a9 8c 60 00 00 04 00 00 00
    Nov 21 15:14:47 Tower kernel: print_req_error: critical medium error, dev sdh, sector 5312712464
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712400
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712408
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712416
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712424
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712432
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712440
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712448
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712456
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712464
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712472
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712480
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712488
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712496
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712504
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712512
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712520
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712528
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712536
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712544
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712552
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712560
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712568
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712576
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712584
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712592
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712600
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712608
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712616
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712624
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712632
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712640
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712648
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712656
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712664
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712672
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712680
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712688
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712696
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712704
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712712
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712720
    Nov 21 15:14:47 Tower kernel: md: disk4 read error, sector=5312712728
    Nov 21 15:15:01 Tower sSMTP[21826]: Creating SSL connection to host
    Nov 21 15:15:01 Tower sSMTP[21826]: SSL connection using TLS_AES_256_GCM_SHA384
    Nov 21 15:15:04 Tower sSMTP[21826]: Sent mail for [email protected] (221 2.0.0 closing connection e27sm1387940lfb.79 - gsmtp) uid=0 username=xxx outbytes=786

     

    Smart report about the error:

    SMART Attributes Data Structure revision number: 16
    Vendor Specific SMART Attributes with Thresholds:
    ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
      1 Raw_Read_Error_Rate     POSR-K   200   200   051    -    9
      3 Spin_Up_Time            POS--K   170   164   021    -    6500
      4 Start_Stop_Count        -O--CK   072   072   000    -    28062
      5 Reallocated_Sector_Ct   PO--CK   200   200   140    -    0
      7 Seek_Error_Rate         -OSR-K   200   200   000    -    0
      9 Power_On_Hours          -O--CK   055   055   000    -    32973
     10 Spin_Retry_Count        -O--CK   100   100   000    -    0
     11 Calibration_Retry_Count -O--CK   100   100   000    -    0
     12 Power_Cycle_Count       -O--CK   083   083   000    -    17784
    192 Power-Off_Retract_Count -O--CK   200   200   000    -    38
    193 Load_Cycle_Count        -O--CK   191   191   000    -    28024
    194 Temperature_Celsius     -O---K   122   108   000    -    28
    196 Reallocated_Event_Count -O--CK   200   200   000    -    0
    197 Current_Pending_Sector  -O--CK   200   200   000    -    0
    198 Offline_Uncorrectable   ----CK   100   253   000    -    0
    199 UDMA_CRC_Error_Count    -O--CK   200   200   000    -    0
    200 Multi_Zone_Error_Rate   ---R--   200   200   000    -    1
                                ||||||_ K auto-keep
                                |||||__ C event count
                                ||||___ R error rate
                                |||____ S speed/performance
                                ||_____ O updated online
                                |______ P prefailure warning
    
    
    SMART Extended Comprehensive Error Log Version: 1 (6 sectors)
    Device Error Count: 1
    	CR     = Command Register
    	FEATR  = Features Register
    	COUNT  = Count (was: Sector Count) Register
    	LBA_48 = Upper bytes of LBA High/Mid/Low Registers ]  ATA-8
    	LH     = LBA High (was: Cylinder High) Register    ]   LBA
    	LM     = LBA Mid (was: Cylinder Low) Register      ] Register
    	LL     = LBA Low (was: Sector Number) Register     ]
    	DV     = Device (was: Device/Head) Register
    	DC     = Device Control Register
    	ER     = Error register
    	ST     = Status register
    Powered_Up_Time is measured from power on, and printed as
    DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
    SS=sec, and sss=millisec. It "wraps" after 49.710 days.
    
    Error 1 [0] occurred at disk power-on lifetime: 32968 hours (1373 days + 16 hours)
      When the command that caused the error occurred, the device was active or idle.
    
      After command completion occurred, registers were:
      ER -- ST COUNT  LBA_48  LH LM LL DV DC
      -- -- -- == -- == == == -- -- -- -- --
      40 -- 51 00 00 00 01 3c a9 8f 10 40 00  Error: UNC at LBA = 0x13ca98f10 = 5312712464
    
      Commands leading to the command that caused the error were:
      CR FEATR COUNT  LBA_48  LH LM LL DV DC  Powered_Up_Time  Command/Feature_Name
      -- == -- == -- == == == -- -- -- -- --  ---------------  --------------------
      60 04 00 00 00 00 01 3c a9 8c 60 40 00 40d+04:22:09.241  READ FPDMA QUEUED
      60 04 00 00 00 00 01 3c a9 88 60 40 00 40d+04:22:09.234  READ FPDMA QUEUED
      60 03 68 00 00 00 01 3c a9 84 f8 40 00 40d+04:22:09.229  READ FPDMA QUEUED
      60 04 00 00 00 00 01 3c a9 80 f8 40 00 40d+04:22:09.222  READ FPDMA QUEUED
      60 00 98 00 00 00 01 3c a9 80 60 40 00 40d+04:22:09.221  READ FPDMA QUEUED

     

    The disk is quite old but I was hoping to utilize it a bit longer. Does this seem bad?

     

    I am planning on changing the SATA cables with another disk to check that if the cable is to blame. Also, I plan to run file system check, extended smart tests and new parity check. Anything else that I should do?

     

    Thank you for any help!