Beiträge von allactionrob

Update: my problem at least is resolved. I had hardware failures of both SATA-to-USB adaptors in my NAS. One had failed completely, the other intermittently. I now have two new adaptors and everything is back to normal again.

Hi all, I have a similar-sounding problem, also running OMV5 on an RPi. I have two SSDs which are both showing on the Disks page, but only one of their corresponding filesystems has mounted ok. The other one seems to be named "/dev/disk/by-label/MainDisk" instead of "/dev/sdb" (MainDisk is the name of the disk). Where has this 'by-label' name come from? Is that why I can't mount it?

Here's what I see:

Cancel that. I opened the box, wiggled all the cables and rebooted and everything seems to be back to normal again. How annoying...but a relief.

Hi,

my NAS has been working fine for months with only occasional reboots. Recently I went to access it and couldn't. Opened the GUI and found one of the filesystems status was 'missing'. I did all the available updates, and a couple of reboots to make sure, and still it's not happy. I have two disks "/dev/sda" and "/dev/sdb". /sdb is missing and doesn't appear when I do 'Scan'. Initially both filesystems were also missing, but after a little while the one for /sda has reappeared and just needed mounting. What can I do to 'find' /sdb? Physically it's an SSD, so it probably hasn't actually failed. I hope.

Thanks, Rob.

Ver 5.5.2-1 running on a RaspberryPi

Ah, some success perhaps!

I did the usb-storage.quirks thing described here: https://www.raspberrypi.org/forums/viewtopic.php?t=245931 and it seems to be working now. Time will tell if it stays working...

Since posting my question I've built a new OMV 5.1.2-1 image on a new microSD card, using Raspian Buster instead of Armbian. Things are a little better, and occasionally it works beautifully, but then goes back to being very flaky. I've just seen in the syslog there's a lot of USB device resetting going on:

Dec 9 18:37:14 NAS kernel: [123359.377671] sd 0:0:0:0: [sda] tag#6 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN
Dec 9 18:37:14 NAS kernel: [123359.377690] sd 0:0:0:0: [sda] tag#6 CDB: opcode=0x28 28 00 00 06 39 08 00 00 08 00
Dec 9 18:37:14 NAS kernel: [123359.377902] sd 0:0:0:0: tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD
Dec 9 18:37:14 NAS kernel: [123359.377915] sd 0:0:0:0: tag#4 CDB: opcode=0x0 00 00 00 00 00 00
Dec 9 18:37:14 NAS kernel: [123359.427685] scsi host0: uas_eh_device_reset_handler start
Dec 9 18:37:14 NAS kernel: [123359.428475] sd 0:0:0:0: [sda] tag#8 uas_zap_pending 0 uas-tag 1 inflight: CMD
Dec 9 18:37:14 NAS kernel: [123359.428492] sd 0:0:0:0: [sda] tag#8 CDB: opcode=0x28 28 00 29 d8 b4 30 00 01 00 00
Dec 9 18:37:14 NAS kernel: [123359.578745] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Dec 9 18:37:15 NAS kernel: [123359.616321] scsi host0: uas_eh_device_reset_handler success
Dec 9 18:37:46 NAS kernel: [123390.738227] sd 0:0:0:0: [sda] tag#25 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN
Dec 9 18:37:46 NAS kernel: [123390.738246] sd 0:0:0:0: [sda] tag#25 CDB: opcode=0x28 28 00 29 d8 e0 c8 00 01 00 00
Dec 9 18:37:46 NAS kernel: [123390.738556] sd 0:0:0:0: [sda] tag#24 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
Dec 9 18:37:46 NAS kernel: [123390.738569] sd 0:0:0:0: [sda] tag#24 CDB: opcode=0x28 28 00 29 d8 e1 c8 00 01 00 00
Dec 9 18:37:50 NAS kernel: [123395.218298] sd 0:0:0:0: [sda] tag#14 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT
Dec 9 18:37:50 NAS kernel: [123395.218317] sd 0:0:0:0: [sda] tag#14 CDB: opcode=0x2a 2a 00 1b c4 84 00 00 00 10 00
Dec 9 18:37:52 NAS kernel: [123396.978321] sd 0:0:0:0: [sda] tag#11 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN
Dec 9 18:37:52 NAS kernel: [123396.978338] sd 0:0:0:0: [sda] tag#11 CDB: opcode=0x28 28 00 1b 81 09 18 00 00 08 00
Dec 9 18:37:52 NAS kernel: [123397.018328] scsi host0: uas_eh_device_reset_handler start
Dec 9 18:37:52 NAS kernel: [123397.169353] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Dec 9 18:37:52 NAS kernel: [123397.207072] scsi host0: uas_eh_device_reset_handler success

Any ideas folks? Thanks.

Hi,
I'm a newbie to OMV, but have some experience of Linux. I've installed OMV 4.1.28-1 on a Raspberry Pi 4B, along with a pair of Kingston 480GB SSDs (via sata-to-USB3 adaptors). I've successfully set up OMV, with one disk as a main store and the other to hold rsync backups. I've configured a SMB/CIFS share to the main store, as well as DLNA service on the same.

My problem is this: when browsing and/or streaming files from my PC or tablet (or smart TV via DLNA), typically everything stops working after a few seconds. Upon checking using the web GUI, the Filesystems page or the Shares page just show "loading". However, at the same time, the Disks page shows the disks ok and an ssh connection indicates everything is file (I can see the disks, and blkid and lsblk seem to do the right things).

A short while later, usually 30-60secs, everything gets going again and the audio/video I'm streaming continues, and the Filesystems / Shares reappear in the web GUI. Oddly, this problem doesn't seem to happen if I simply copy a large file (although the transfer speed is very variable, from ~100MB/s initially down to <10MB/s a few secs later - I'm assuming that's just Windows being rubbish).

Any ideas?
Rob.