NAS / OpenMediaVault

[thatguyyouknowtheone]

Hey guys, I followed this guide to a Tee. https://www.youtube.com/watch?v=gT-EGNl9bZA&t=3s
And it worked up until teh very last step where you try to input your security credentials in on windows 10 to login to the NAS. Windows will not accept my password. I can login to the OMV just fine with my IP otherwise tho. Ive googled the problem extensively and changed jsut about every network or otherwise mentioned setting and still to no avail with rebooting NAS and comp at every step. Help?

[mruano]

Hello

I have been running Open Media Vault 4.1.21-1 (arrakis) and Logitech Media Server 7.9.2 together on a Raspberry Pi 3B attached to a dual bay IcyBox Ib-3662u3 (Prolific 2773 chipset) with two 8+8 Tb 3.5” HDDs for quite some time without any issues – except occasionally it can be a bit slow.

I wanted more speed (and I admit that I have been worried about tkayser’s repeated warnings in these forums about the Raspberry potentially causing HDD data corruption), so I decided to upgrade to the Rock64 with 4Gb and, crucially, USB 3. However, the Rock64 does not seem capable of running both OMV and LMS simultaneously without crashing – in fact, I am not sure it can run either separately – which is actually quite surprising because the Raspberry handles both OMV and LMS quite well.

I have scrupulously followed the specified instructions to flash the Rock64 OS images to the SD cards and eMMc modules, using Etcher, good quality SD cards, the recommended software sources, etc.

I have tried several versions of OS (Ayufan’s Linux and Armbian from armbian.com and Sourceforge), plus several versions of LMS – all without joy.

I have been in touch with Pine’s Support Team and this has been their reply:

“Support USB 3.0 HDD transfer can be tricky, especially with UASP enable. This highly pending on your USB 3.0 to SATA cable (especially with ASM chipset) whether able to handle UASP transfer well. Raspberry Pi doesn't has such issue due to it only can operation in USB 2.0 bus. Sorry that we aware about such issue but we are not expert that able to help you to resolve further. You bring up this topic at Armbian forum or chat with developer that has such experience on PINE64 IRC (http://pine64.xy then /join #rock64)
This design fault is not related to ROCK64 SBC.”

Which makes me wonder, whose fault is it then?

Anyhow, I am now thinking of the Odroid C2 as a better alternative ‘upgrade’ to my Raspberry OMV+LMS setup.

Any views, suggestions or advice out there?

Thanks in advance for any tips.

[mandreozzi]

Hi from Argentina!!!

Tell me what do you think about this...

https://www.aliexpress.com/item/ACASIS-d...909566.htm

Not to be a fan of the brand but the original pine64 one is totally known to work:
https://www.pine64.org/?product=usb-3-0-...-with-uasp
and cheaper since we go thru a hard time, btw im also from Argentina, hola amigo


PD: por cierto, mira esto:
https://articulo.mercadolibre.com.ar/MLA...151204-_JM
si le agregas lo que vas a pagar de importación hasta te sale mas barato todavía, y es local o sea que cualquier problema tenes a quien reclamar...

Thanks for your answer, but the idea was to present an option to create a RAID through a USB 3.0 port

PD.: a ese vendedor lo conozco cuando le compré la memoria EMMC ya que cuando la quise comprar en el Store estaba agotada.

Sorry for the delay, but I can confirm that the device works correctly, it is a great option for our Rock64 !!!! 

[iscmob]

Hi,

I'm super new to OMV, Linux, and everything else.
I managed to build OMV with a 2TB disk. It's pretty awesome journey from zero knowledge and many readings.

Now, after I managed to install rclone and connected to my Google Drive (as GDrive), I encountered a few problems that I don't know how to solve.

1. Checking Rclone Sync command.
I have GDrive:/Testing folder with a pdf file. And I want a testing to sync this pdf to my OMV disk 'iz' folder. 'iz' folder is a shared folder created on the 2TB disk (with the name DATA).

Here's my command for the testing.
rclone sync GDrive:/Testing /srv/dev-disk-by-label-DATA/iz
After this, the terminal just go back my to pi@...$

So, may I know how to check whether the command did what it suppose to do.
BTW, I check the OMV drive remotely and I did not see the pdf was copied over with the rclone sync command.

2. Problem accessing the sda1
My lsblk for my OMV is:
pi@... $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1.8T 0 disk
└─sda1 8:1 0 1.8T 0 part /srv/dev-disk-by-label-DATA
mmcblk0 179:0 0 14.8G 0 disk
├─mmcblk0p1 179:1 0 256M 0 part /boot
└─mmcblk0p2 179:2 0 14.5G 0 part /

Please kindly advise. I believe problems 1 and 2 are connected. I just don't know how to proceed further. Thanks.

[pfeerick]

So, may I know how to check whether the command did what it suppose to do.

If you didn't get any output at all, try running it again with the -v (as in verbose) flag. Add more v's (i.e. -vvv) for more verbose output. You can also add -n (or --dry-run) if you want to do so without the risk of any data being lost. I can't remember if with rclone you need to add a trailing slash to one of the paths to address it properly - probably the destination, if you want the "testing" folder inside "iz".

2. Problem accessing the sda1

I'm not sure what you're trying to say the problem is here... "/srv/dev-disk-by-label-DATA" is correct for OMV. So if you do a "ls /srv/dev-disk-by-label-DATA" you should see the contents of that drive. e.g. Is the "iz" listed?

[iscmob]

Thanks pfeerick for your advice.

1. rclone sync GDrive:/Testing /srv/dev-disk-by-label-DATA/iz
Using Dolphin, I could see the .pdf file from "GDrive:/Testing" copied (or synced) to my OMV "iz" folder.
According to rclone sync command (typing "rclone sync -h"), sync command does what copy command does, by copying everything from source to destination without creating the source folder in the process.

And I created a sub-folder under GDrive:/Testing and did the same command (this time I include a new flag '-P') and noted the sub-folder was created accordingly. The rclone sync command copies everything including the sub-folder.
Awesome!

The only challenge is I have to reset my PBP and order to use Dolphin to see the sync's work done. I couldn't see the result of the rclone sync immediately through Dolphin. I need to reset PBP. Strange.

2. ls /dev-disk-by-label-DATA/iz
But when I tried to do the above in the terminal, i got the following error message. I don't understand why it doesn't allow me to see the folder.
pi@...:/srv $ ls /dev-disk-by-label-DATA/iz
ls: cannot access '/dev-disk-by-label-DATA/iz': No such file or directory

And I used rclone ls command, I got the same error message.
pi@...:~ $ rclone ls /dev-disk-by-label-DATA/iz
2020/07/31 16:19:55 ERROR : : error listing: directory not found

But I know the sub-folder has been created and all the contents were synced accordingly.

Do enlighten me if you all have further insights.

3. pi@...:~ $ rclone check GDrive:/Testing /srv/dev-disk-by-label-DATA/iz
2020/07/31 16:38:41 NOTICE: Local file system at /srv/dev-disk-by-label-DATA/iz: 0 differences found
2020/07/31 16:38:41 NOTICE: Local file system at /srv/dev-disk-by-label-DATA/iz: 2 matching files

This is a great command to check both source and destination has zero difference and 100% matching. Awesome and simple Linux command.

[iscmob]

I managed to find a way to refresh Dolphin by F5 in order to see the latest synced results.

[pfeerick]

pi@...:/srv $ ls /dev-disk-by-label-DATA/iz
ls: cannot access '/dev-disk-by-label-DATA/iz': No such file or directory

pi@...:~ $ rclone ls /dev-disk-by-label-DATA/iz

In the first instance, your working directory was `/srv/`, so your ls command should have not have had the leading `/`, or should been the complete path - with `/srv` in front.

In the second, the path was again wrong... `/srv` was missing from the front of the path.

Sounds like you're making progress though!

[iscmob]

pi@...:/srv $ ls /dev-disk-by-label-DATA/iz
ls: cannot access '/dev-disk-by-label-DATA/iz': No such file or directory

pi@...:~ $ rclone ls /dev-disk-by-label-DATA/iz

In the first instance, your working directory was `/srv/`, so your ls command should have not have had the leading `/`, or should been the complete path - with `/srv` in front.

In the second, the path was again wrong... `/srv` was missing from the front of the path.

Sounds like you're making progress though! 

thank you so much buddy!
You are absolutely right! Appreciate your explanation!
Awesome, Awesome! Awesome!