fysmd

Members
  • Posts

    107
  • Joined

  • Last visited

Posts posted by fysmd

  1. I have three USB devices which I pass through to HOmeassistant in a VM, these have been working well and conneect on boot sucessfully for a long time now, They are all assigned to the VM:

    image.thumb.png.b8aeaca692c7ebc49e89f5b137d344cf.png

     

     

    Dec 29 10:15:53 Server kernel: usb 1-13: USB disconnect, device number 8
    Dec 29 10:15:53 Server kernel: usb 1-13.1: USB disconnect, device number 9
    Dec 29 10:15:54 Server kernel: usb 1-13: clear tt 1 (90a2) error -110
    Dec 29 10:15:54 Server kernel: usb 1-13.4: USB disconnect, device number 10
    Dec 29 10:15:54 Server usb_manager: Info: rc.usb_manager usb_remove   /dev/bus/usb/001/010 001 010 
    Dec 29 10:15:54 Server usb_manager: Info: rc.usb_manager Device Match 001/010 vm: HomeAssistant  001 010 
    Dec 29 10:15:54 Server usb_manager: Info: rc.usb_manager usb_remove   /dev/bus/usb/001/009 001 009 
    Dec 29 10:15:54 Server kernel: usb 1-13: new high-speed USB device number 11 using xhci_hcd
    Dec 29 10:15:54 Server usb_manager: Info: virsh called HomeAssistant 001 010 Device detached successfully  
    Dec 29 10:15:54 Server usb_manager: Info: rc.usb_manager Disconnect  001/010 vm: HomeAssistant running 001 010 
    Dec 29 10:15:54 Server usb_manager: Info: rc.usb_manager Removed 001/010 vm: HomeAssistant running 001 010
    Dec 29 10:15:54 Server kernel: hub 1-13:1.0: USB hub found
    Dec 29 10:15:54 Server kernel: hub 1-13:1.0: 4 ports detected
    Dec 29 10:15:54 Server usb_manager: Info: rc.usb_manager usb_remove   /dev/bus/usb/001/008 001 008 
    Dec 29 10:15:54 Server usb_manager: Info: rc.usb_manager Device Match 001/008 vm:   001 008 
    Dec 29 10:15:54 Server usb_manager: Info: rc.usb_manager Removed 001/008 vm:  nostate 001 008
    Dec 29 10:15:54 Server usb_manager: Info: rc.usb_manager usb_add 1a40_USB_2.0_Hub /dev/bus/usb/001/011 001 011
    Dec 29 10:15:54 Server kernel: usb 1-13.1: new full-speed USB device number 12 using xhci_hcd
    Dec 29 10:15:55 Server kernel: ch341 1-13.1:1.0: ch341-uart converter detected
    Dec 29 10:15:55 Server kernel: usb 1-13.1: ch341-uart converter now attached to ttyUSB0
    Dec 29 10:15:55 Server kernel: usb 1-13.4: new full-speed USB device number 13 using xhci_hcd
    Dec 29 10:15:55 Server kernel: ftdi_sio 1-13.4:1.0: FTDI USB Serial Device converter detected
    Dec 29 10:15:55 Server kernel: usb 1-13.4: Detected FT232RL
    Dec 29 10:15:55 Server kernel: usb 1-13.4: FTDI USB Serial Device converter now attached to ttyUSB1
    Dec 29 10:15:55 Server usb_manager: Info: rc.usb_manager Autoconnect No Mapping found 1a40_USB_2.0_Hub /dev/bus/usb/001/011 001 011 port 1-13
    Dec 29 10:15:55 Server usb_manager: Info: rc.usb_manager tty_add 1a86_USB_Serial /dev/ttyUSB0  
    Dec 29 10:15:55 Server usb_manager: Info: rc.usb_manager tty_add SHK_NANO_CUL_868 /dev/ttyUSB1  
    Dec 29 10:15:55 Server usb_manager: Info: rc.usb_manager Processing tty attach 1a86_USB_Serial /dev/ttyUSB0  
    Dec 29 10:15:55 Server usb_manager: Info: rc.usb_manager Autoconnect No Mapping found 1a86_USB_Serial /dev/ttyUSB0   port 
    Dec 29 10:15:55 Server usb_manager: Info: rc.usb_manager Processing tty attach SHK_NANO_CUL_868 /dev/ttyUSB1  
    Dec 29 10:15:55 Server usb_manager: Info: rc.usb_manager Autoconnect No Mapping found SHK_NANO_CUL_868 /dev/ttyUSB1   port 
    Dec 29 10:15:55 Server usb_manager: Info: rc.usb_manager usb_add 1a86_USB_Serial /dev/bus/usb/001/012 001 012
    Dec 29 10:15:55 Server usb_manager: Info: rc.usb_manager usb_add SHK_NANO_CUL_868 /dev/bus/usb/001/013 001 013
    Dec 29 10:15:56 Server usb_manager: Info: rc.usb_manager Autoconnect Parent 1-13
    Dec 29 10:15:56 Server usb_manager: Info: rc.usb_manager Autoconnect No Mapping found 1a86_USB_Serial /dev/bus/usb/001/012 001 012 port 1-13.1
    Dec 29 10:15:56 Server usb_manager: Info: rc.usb_manager Autoconnect Parent 1-13
    Dec 29 10:15:56 Server usb_manager: Info: rc.usb_manager Autoconnect No Mapping found SHK_NANO_CUL_868 /dev/bus/usb/001/013 001 013 port 1-13.4

     

    Any tips / tricks / hints greatly appreciated..

     

    server-diagnostics-20221230-0909.zip

  2. Hi, I am running 6.9.2 and noticed errors in syslog this morning which I think suggest one of mt cache pool drives is misbehaving but there are no errors displayed anywhere, nor any note on that drive - are these just info or should I change this drive?

     

     

    Dec 30 07:44:06 Server kernel: sd 7:0:8:0: attempting task abort!scmd(0x0000000094d60fd2), outstanding for 30352 ms & timeout 30000 ms
    Dec 30 07:44:06 Server kernel: sd 7:0:8:0: [sdp] tag#4543 CDB: opcode=0x28 28 00 03 20 d8 00 00 00 08 00
    Dec 30 07:44:06 Server kernel: scsi target7:0:8: handle(0x0021), sas_address(0x300062b202f04009), phy(9)
    Dec 30 07:44:06 Server kernel: scsi target7:0:8: enclosure logical id(0x500062b202f04000), slot(18) 
    Dec 30 07:44:06 Server kernel: scsi target7:0:8: enclosure level(0x0000), connector name(     )
    Dec 30 07:44:06 Server kernel: sd 7:0:8:0: task abort: SUCCESS scmd(0x0000000094d60fd2)
    Dec 30 07:44:06 Server kernel: sd 7:0:8:0: [sdp] tag#4543 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=0x00 cmd_age=30s
    Dec 30 07:44:06 Server kernel: sd 7:0:8:0: [sdp] tag#4543 CDB: opcode=0x28 28 00 03 20 d8 00 00 00 08 00
    Dec 30 07:44:06 Server kernel: blk_update_request: I/O error, dev sdp, sector 52484096 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
    Dec 30 07:44:06 Server kernel: sd 7:0:8:0: attempting task abort!scmd(0x00000000d67ffc34), outstanding for 30382 ms & timeout 30000 ms
    Dec 30 07:44:06 Server kernel: sd 7:0:8:0: [sdp] tag#4541 CDB: opcode=0x28 28 00 03 20 56 08 00 00 08 00
    Dec 30 07:44:06 Server kernel: scsi target7:0:8: handle(0x0021), sas_address(0x300062b202f04009), phy(9)
    Dec 30 07:44:06 Server kernel: scsi target7:0:8: enclosure logical id(0x500062b202f04000), slot(18) 
    Dec 30 07:44:06 Server kernel: scsi target7:0:8: enclosure level(0x0000), connector name(     )
    Dec 30 07:44:06 Server kernel: sd 7:0:8:0: No reference found at driver, assuming scmd(0x00000000d67ffc34) might have completed
    Dec 30 07:44:06 Server kernel: sd 7:0:8:0: task abort: SUCCESS scmd(0x00000000d67ffc34)
    Dec 30 07:44:06 Server kernel: sd 7:0:8:0: [sdp] tag#4541 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=0x00 cmd_age=30s
    Dec 30 07:44:06 Server kernel: sd 7:0:8:0: [sdp] tag#4541 CDB: opcode=0x28 28 00 03 20 56 08 00 00 08 00
    Dec 30 07:44:06 Server kernel: blk_update_request: I/O error, dev sdp, sector 52450824 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0

     

    complete diag attached.

    server-diagnostics-20221230-0909.zip

  3. Thanks for your help.  My drives have remained stable and parity2 (just) completed building.

     

    I need to work out how to get the probably-fine-but out of the darray drive back in there now but I'l going to leave it for another day - for us both to recover a bit ;)

    Bought some larger drives for parity(s) so they can go in once all back to normal..

     

    KR

    Ian.

  4. Thank-you.

    I paused the parity rebuild, and fixed the fs in maint mode.

     

    Just restarted and partiy build is continuing on 2nd parity disk.

    Failed drive still emulated (red cross) but does not show unmountable any more.

     

    I have a spare drive so once parity2 is done I'll rebuild to that one..

  5. Ok I checked and it's almost certainly power, all drives which barfed were on the same cable.  I was not able to replace all components but that which I could has been replaced and all reseated and run more neatly...

     

    Unraid started up again but now one of the drives shows as unmountable, new diag attached.

    As it shows unmountable and so not emulated, have I just lost data??

     

    image.thumb.png.d96b7cc9b15bfe6ff23edefac99eb563.png

    server-diagnostics-20220406-2034.zip

  6. Hi all, Happy New Year!!

    A little help please:

     

    I had an HDD fail so replaced with an alreay prepared replacement HDD (I once had multiple fail and no spares to hand!).

    After powering down to replace that drive, my cache SSD died totally, not even spotted in BIOS!  I dont have a spare so running for a while without a cahche drive.

     

    I have recreated appdata share and restored from ca.backup (took an eterninty!) and rebooted but no docker containers have reappeared after a reboot.

    My container config is still there:

    root@Server:/boot/config/plugins/dockerMan/templates-user# ls
    my-Cacti.xml             my-EmbyServer.xml  my-HDDTemp.xml   my-QDirStat.xml      my-matrix.xml     my-tasmobackup.xml
    my-CloudBerryBackup.xml  my-FileBot.xml     my-Influxdb.xml  my-duplicati.xml     my-nextcloud.xml  my-tautulli.xml
    my-DiskSpeed.xml         my-FileZilla.xml   my-Minio.xml     my-ferdi-server.xml  my-plex.xml       my-telegraf.xml
    my-Duplicacy.xml         my-Grafana.xml     my-Netdata.xml   my-glances.xml       my-plex22.xml

     

    Unraid prop 6.8.3, diag attached.

     

     

    I could just recreate my containers manually but shouldn't they have recovered after the steps I've taken?

    server-diagnostics-20210101-1652.zip

  7. I have see the same on ubuntu 18 host AND a 2nd unrid server using unassigned devices to mount.  Spent ages thinking it was a problem with unassigned devices plugin...

    I notice that the web UI on the server machine runs VERY slowly once this issue begins.

    Noting obvs in any logs anywhere :(

     

    Switching to vers=1.0..

  8. OK, so Sunday update:

    Music share has gone offline again this morning.

    vh1-diagnostics-20200503-1035.zip

     

    I dont see anything obvs in syslog - what do you think?

     

    Server machine:

    eth0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
            ether bc:5f:f4:d2:db:d4  txqueuelen 1000  (Ethernet)
            RX packets 2477677922  bytes 3071357019049 (2.7 TiB)
            RX errors 5  dropped 533  overruns 0  frame 5
            TX packets 3155609402  bytes 4322561158105 (3.9 TiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 20  memory 0xf0700000-f0720000
    
    eth1: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
            ether bc:5f:f4:d2:db:d4  txqueuelen 1000  (Ethernet)
            RX packets 130740224  bytes 17696208835 (16.4 GiB)
            RX errors 41312  dropped 100132  overruns 0  frame 41312
            TX packets 333590388  bytes 442915979439 (412.4 GiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

     

     

    Client machine:

    docker@VH1:~$ ifconfig eth0
    eth0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500
            ether d8:cb:8a:14:10:d9  txqueuelen 1000  (Ethernet)
            RX packets 315521459  bytes 408413770038 (380.3 GiB)
            RX errors 0  dropped 2992  overruns 0  frame 0
            TX packets 119869768  bytes 23267646022 (21.6 GiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 19
    
    docker@VH1:~$ ethtool -S eth0
    NIC statistics:
         rx_packets: 315619207
         rx_bcast_packets: 396272
         rx_mcast_packets: 588699
         rx_pause_packets: 0
         rx_ctrl_packets: 2995
         rx_fcs_errors: 0
         rx_length_errors: 0
         rx_bytes: 408481320459
         rx_runt_packets: 0
         rx_fragments: 0
         rx_64B_or_less_packets: 1757734
         rx_65B_to_127B_packets: 1000264
         rx_128B_to_255B_packets: 39357056
         rx_256B_to_511B_packets: 6591231
         rx_512B_to_1023B_packets: 4971266
         rx_1024B_to_1518B_packets: 261944652
         rx_1519B_to_mtu_packets: 0
         rx_oversize_packets: 0
         rx_rxf_ov_drop_packets: 0
         rx_rrd_ov_drop_packets: 0
         rx_align_errors: 0
         rx_bcast_bytes: 45617284
         rx_mcast_bytes: 184470451
         rx_address_errors: 0
         tx_packets: 119944390
         tx_bcast_packets: 1902
         tx_mcast_packets: 9153
         tx_pause_packets: 0
         tx_exc_defer_packets: 0
         tx_ctrl_packets: 0
         tx_defer_packets: 0
         tx_bytes: 23281052097
         tx_64B_or_less_packets: 67518
         tx_65B_to_127B_packets: 60869104
         tx_128B_to_255B_packets: 49266597
         tx_256B_to_511B_packets: 3280260
         tx_512B_to_1023B_packets: 154673
         tx_1024B_to_1518B_packets: 6306238
         tx_1519B_to_mtu_packets: 0
         tx_single_collision: 0
         tx_multiple_collisions: 0
         tx_late_collision: 0
         tx_abort_collision: 0
         tx_underrun: 0
         tx_trd_eop: 0
         tx_length_errors: 0
         tx_trunc_packets: 0
         tx_bcast_bytes: 161174
         tx_mcast_bytes: 1320031
         tx_update: 0
    docker@VH1:~$

     

    Drops look to be control packets on client machine but many more (numerically) on eth1 on server.

    I'm going to disable eth1 port on the server machine..  [guess]

     

    Also, as I've rebooted server upgraded it to 6.8.3 (same as client machine)

     

  9. they autoupdate but I did it manually earlier.

    For info, how would containers impact (host) system mounts?

      The containers do map to these CIFS mounts (with slave option).

     

    Syslog:

    May  2 12:51:41 VH1 kernel: CIFS VFS: Close unmatched open
    May  2 12:53:11 VH1 kernel: CIFS VFS: Close unmatched open
    May  2 12:58:14 VH1 kernel: CIFS VFS: Close unmatched open
    May  2 12:59:09 VH1 kernel: CIFS VFS: Autodisabling the use of server inode numbers on \\SERVER\downloads. This server doesn't seem to support them properly. Hardlinks will not be recognized on this mount. Consider mounting with the "noserverino" option to silence this message.
    May  2 12:59:10 VH1 kernel: CIFS VFS: Autodisabling the use of server inode numbers on \\SERVER\movies. This server doesn't seem to support them properly. Hardlinks will not be recognized on this mount. Consider mounting with the "noserverino" option to silence this message.
    May  2 12:59:14 VH1 kernel: CIFS VFS: Close unmatched open
    May  2 12:59:45 VH1 kernel: CIFS VFS: Close unmatched open
    May  2 13:01:46 VH1 kernel: CIFS VFS: Close unmatched open
    May  2 13:02:46 VH1 kernel: CIFS VFS: Close unmatched open

     

  10. all put back to 1500 last night as reported.

    One CIFS share down again this morning :(

    in "Main" on web UI, UD shows "music" as mounted but with zero size,used and free.

     

    Linux 4.19.107-Unraid.
    docker@VH1:~$ df -h
    Filesystem          Size  Used Avail Use% Mounted on
      <snip>
    //SERVER/TV          66T   45T   21T  69% /mnt/disks/SERVER_TV
    //SERVER/music       66T   45T   21T  69% /mnt/disks/SERVER_music
    //SERVER/movies      66T   45T   21T  69% /mnt/disks/SERVER_movies
    docker@VH1:~$ ls /mnt/disks/SERVER_music
    /bin/ls: cannot access '/mnt/disks/SERVER_music': Stale file handle
    docker@VH1:~$

     

    and still lots of "unmatched open" in syslog.

     

    vh1-diagnostics-20200502-0915.zip

  11. so machine ran overnight and this morning I have a different CIFS share in the broken state.

    Could it be that they fail due to inactivity?

    I'm going to scipt ls of a large directory every five mins to see if that prevents.

     

    For info, I'm doing this because my cherished NUC has passed.  I was running ubuntu14 LTS on there and had zero CIFS mount issues they were rock solid.

    vh1-diagnostics-20200430-1059.zip

  12. LOL!  I thought exactly what you say and that's same as in help.  In reality though it seems to fill the cache and then complain / fail :( Wondering if I need to combine wiht with a different min free value or something.   .. or maybe the machin was in a funk at the time and just needed restarting.

     

    Yes, I'm a very long time user, the "server" is my (now) very stable box but I'm testing out another one to host some containers and virtual machines.   On an eval license and using old disks which wile working, were removed from my live arrar due to the smart warnings.

     

  13. So a reboot fixed Time discrepancies (the web ui and cli: date both reported correct local time but not syslog)

    and the cache disk is no longer full (prefer cache on share  doesnt seem to do what I expected!). 

     

    and so far the CIFS mount is stable (and so my cache disk no longer full)

     

    Syslog full of:

    Apr 30 15:11:30 VH1 kernel: CIFS VFS: Close unmatched open
    Apr 30 15:13:00 VH1 kernel: CIFS VFS: Close unmatched open
    Apr 30 15:17:01 VH1 kernel: CIFS VFS: Close unmatched open
    Apr 30 15:17:01 VH1 kernel: CIFS VFS: Close unmatched open
    Apr 30 15:19:01 VH1 kernel: CIFS VFS: Close unmatched open
    Apr 30 15:20:02 VH1 kernel: CIFS VFS: Close unmatched open
    Apr 30 15:20:33 VH1 kernel: CIFS VFS: Close unmatched open

     

    Are they relevant?

     

  14. Sorry in advance if answered in this (LONG) thread but I've searched and can't find same issue:

     

    Two unraid servers running 6.8.2 [server] and 6.8.3 [client] both on physical boxes.  diag attached for client machine.

    I run UD on both but I want to mount my media shares using CIFS with UD on the client server.

     

    Many work well and are stable but my movies share is not.

    sometimes it mounts and works for a period but once it fails it shows mounted on the GUI and in CLI but navigating into share un GUI takes a long time but shows it empty.  In cli:

    root@VH1:~# ls /mnt/disks/SERVER_movies
    /bin/ls: cannot access '/mnt/disks/SERVER_movies': Stale file handle

     

    syslog reports sucessful mount despite it not bing and syslog full of:

    root@VH1:~# ls /mnt/disks/SERVER_movies
    /bin/ls: cannot access '/mnt/disks/SERVER_movies': Stale file handle

     

    I notice that the time shown in syslog must be in a different timezone, machine reports time correctly but logs are -7h

     

    ( I know my cache disk full at the mo BTW! and a couple of HHDs are reporting smart errors, I'm in eval at the mo while I try to get this puppie working how I want )

     

    vh1-diagnostics-20200430-1059.zip