I don't think so, in general an error means that everything was stopped, I don't think linux would do a partial mount. It can be an alias for some other thing, but as you may have guessed, that's not the way I do things, maybe they are right to do this like it is but I don't understand why. I find it complicated and messy. I understand that the problem is solved ? you issued the SSH command and it worked ?
I don't think so, in general an error means that everything was stopped, I don't think linux would do a partial mount. It can be an alias for some other thing, but as you may have guessed, that's not the way I do things, maybe they are right to do this like it is but I don't understand why. I find it complicated and messy. I understand that the problem is solved ? you issued the SSH command and it worked ?
Yes The front USB is OK now
Apparently firmware 6.1.5 has introduce some incompatblities in the USB3 ports so Netgear are investigating.
To remount your things as read write, there is no need to change any file as this gets mounted on the fly with settings that are decided on the fly (maybe there is a setting in some file about that but not that we can change):
So I see the 2 critical lines from your mount commands are this:
# mount /dev/sdf2 on /media/USB/dev/sdf2 on /media/USB_HDD_1 type ufsd (ro,noatime,nodiratime,nls=utf8,fmask=0,dmask=0) /dev/sdf2 on /run/nfs4/media/USB_HDD_1 type ufsd (ro,noatime,nodiratime,nls=utf8,fmask=0,dmask=0)
To remount (smoothly) anything in linux without needing to unmount it first then mount it again:
# mount -o remount,rw /media/USB/dev/sdf2 # mount -o remount,rw /run/nfs4/media/USB_HDD_1
----
Or you can do it the annoying way (where you unmount and then mount)
# umount /media/USB/dev/sdf2 # mount -o rw /dev/sdf2 /media/USB/dev/sdf2
# umount /run/nfs4/media/USB_HDD_1 # mount -o rw /dev/sdf2 /run/nfs4/media/USB_HDD_1
----
You will need to do it to both places. Confirm with:
# mount
It should say
/dev/sdf2 on /media/USB/dev/sdf2 on /media/USB_HDD_1 type ufsd (rw,noatime,nodiratime,nls=utf8,fmask=0,dmask=0) /dev/sdf2 on /run/nfs4/media/USB_HDD_1 type ufsd (rw,noatime,nodiratime,nls=utf8,fmask=0,dmask=0)
SIDE NOTE1: The mount commands syntax is, each term i put in () so as to see where they begin and end (also order -o and -t doesnt matter, only order of device and mount location matters. device first, mount location second. You can put the "-o option" and "-t type" at the very end of the mount command:
mount (-o option1,option2 - also optional but not for remounting) (-t type of file system - usually optional as it will detect it) (device like /dev/sdf2 - this is optional when your working on a mount thats already mounted) (mount location - aka destination)
SIDE NOTE2:
To remount as read only
# mount -o remount,ro /media/USB/dev/sdf2 # mount -o remount,ro /run/nfs4/media/USB_HDD_1
The subject says it all....... I copied a couple of cdrom iso''s to the nas and then then frontview disconnected and network access was down. It lasted about 10 15 minutes before it was back online. This is sad..... Will whe have to factory reset again with the next firmware?
I can confirm this. Updated via frontview to the newly released 6.1.5 firmware, did a factory reset (I had already saved all my data to external drives (7Tb space) hooked up to my PC). The system started fine, reconfigured everything the way I want it and started uploading the data back. I am not even at 400Gb of the roughly 4.9TB I need to put back and already the unit hung itself at least 8 times. (It is hanging as we speak) Like dishmagic66 states; after roughly 10 - 15 minutes it will unfreeze again and the upload will continue.
In short: The problem has NOT been fixed, it has been made worse. I only decided to try 6.1.5 as this would solve the problem. I'll now just bite the bullet, shelve out extra money and get me a NAS that actually works (hint: NO MORE NETGEAR)
Somebody else already said this, but is there ANY quality control at Netgear? These type of problems are unacceptable.
Anyone interested in buying a RN104 (without the disks) in original packaging. Bought in May 2013. "Good as new". (Just bought myself another NAS from another manufacturer as I am fed up with the problems with the RN104)
well, Here's my situation... in the end I've update to 6.1.5 and I'm restoring my backupped data (about 5TB on 3x 3tb seagate disks). I'm using mucommander on a mac mini with os x 10.9.1 and the transfer speed graph is a rollercoaster (from 0 to 26Mps and again to 0 every 20 to 30 seconds...). It took me 3 hours and 8 minutes to transfer 200GB from usb3 hard disk to the nas using AFP (similar speed using SMB but I've not tested that long) and a cat6 cable between the mac and the nas (no switches or hubs). Now it could be because the rebuild in the background (still 8 hours to go) but with version 6.1.4 that did not happened. Returning on topic, I've contacted the support and they told me something interesting: * they will not provide free hard drives to backup my data so I can proceed to factory reset to fix the btrfs problems (U was expecting this so I borrowed lot of smaller disks at office...). A little side note: I have only large files on the nas (10 to 40GB each) and btrfs stats seems normal. I've filled the nas up to 95% with no problems on 6.1.4 * about the usb3 ports problem: they don't read the forums and the forums are not official. they have no record of this problem in their databases. In additional the support has no usb3 drive to do the tests * about the afp shares being disconnected when an usb disk il plugged in / removed problem: they don't read the forums and the forums are not official. they have no record of this problem in their databases. In additional the support has no macs nor usb3 drive to do the tests * about the performance drop from 40-50MBps to 20-25MPbs after I've added the 2nd and 3rd drive I've got no answer except the offer to make the support check my config (I work on linux server since ages, I've already done my homework)
After that I've asked to be a readynas beta tester (so at least I use official betas and non stable releases that are beta quality). As today thumbs down for the hardware, for the software and for the support (at least they answered me...) I will switch to another nas as soon as I have the money/need but for now I have wasted enough time moving data around...
with 6.1.6 usb3 is not fixed for me. in additiona when I plug in a disk in any usb port the nas seems to freeze... it seems ntfs support have been dropped out too
I have more result for ntfs on my RN516 runing 6.1.6
I checked in 6.1.5 (just rollbacked) and I have the same results. will check other versions asap
could you check for hfs, please ? I don't remember if it was supported in past versions... in 6.1.5 I have a bunch of stuff in /sys/kernel/slab so it seems to be compiled into kernel
6.1.6 RC3 has seemed to have cured my USB3 issues. RAID5 USB3 external unit formatted in NTFS is now stable and not disconnecting Large file transfers were OK using 6.1.5 some freezing but cancelling and restarting the file transfer seemed to resolve this after a perod of time elapses, the NAS comes back online! according to the web interface Intial tests of large file transfers using 6.1.6RC3 seemed OK as well.
I hope that this is a fix but I will not get too carried away
Posted too soon
Transfering 4.5GB file from PC to NAS and frozen!! (6.1.6RC3) 4* 4TB HDD with 2TB free space
Freezes cannot put anymore files on need to pull plug and reconnect power to use NAS tried multiple times
I tried loading files via FTP and I had no problems at all. I was able to write to the NAS at 40MB/s and read at 93MB/s. Both ran for hours without any issues. The files ranged from a few megabytes to over 8 terabytes. In both cases I varied the number of simultaneous transfers from 1 to 10 and I didn't see any issues.
Just posted this on the 6.6RC3 i/O thread but adding here for completeness
Large file transfer over SMB was ok using 6.1.5 installing 6.1.6 to regain USB3 use seems to have broken this This was tried on a RN104 with 4*4TB HDD transfered 8TB using SMB under 6.1.5 (factory reset) then another 2TB, then updated firmware to 6.1.6 and the problems started with 1.9TB free space on NAS. Attempting to transfer 4.35GB via SMB, freezes Also tried FTP but no go also freezing. Is it the RC3 patches for "better I/O"?
This is reminiscent of the NV+ V2 issue where a subsequent firmware update brought back this exact issue on this series of boxes
Just checked another box RN105 6.1.6 this had 10.5TB transfered under 6.1.5 after a factory reset. Updated to 6.1.6 and transfered exactly the same file of 4.35GB via smb from the same computer OK
I have the feeling that if i removed say 1.5TB from this NAS and then tried to restore the same the freezing would start. (Of course there is NO WAY that I am going to test this, I do not have the time or funds to purchase more disc space to do the factory reset again) This is exactly what happened in the ReadyNAS V2 debacle (my use of the term debacle)
Reverted to 6.1.5 on the NAS that freezes and the 4.35GB file is transferred via SMB (probably all protocols would now work).
Did some more digging in the backup issue. (after a backup job is done, fvbackup-q keeps running at maximum processor load and this makes the nas really slow) jobs
The same problem exists in OS 6.1.6. When I killed fvbackup-q the processor load dropped to 10 % (from 98 %).
BTW, what command restarts fvbackup-q? /frontview/bin/fvbackup-q sais 'This program should be started by systemd'.
Did some more digging in the backup issue. (after a backup job is done, fvbackup-q keeps running at maximum processor load and this makes the nas really slow) jobs
The same problem exists in OS 6.1.6. When I killed fvbackup-q the processor load dropped to 10 % (from 98 %).
BTW, what command restarts fvbackup-q? /frontview/bin/fvbackup-q sais 'This program should be started by systemd'.
Did some more digging in the backup issue. (after a backup job is done, fvbackup-q keeps running at maximum processor load and this makes the nas really slow) jobs
The same problem exists in OS 6.1.6. When I killed fvbackup-q the processor load dropped to 10 % (from 98 %).
BTW, what command restarts fvbackup-q? /frontview/bin/fvbackup-q sais 'This program should be started by systemd'.
I'm having an issue that seems to be similar to others here with freezing during large file transfers, and also freezing at seemingly random times when using DLNA. I'd like to know how to downgrade the firmware back to 6.1.4 (where I was having no problems).
I have a WD MyBook 3TB USB 3.0 and it was working perfectly fine at 6.1.4 (able to read/write over 100MB/sec over gigabit) from/to clients, nearly the same as directly connected to USB 3.0 on PC(120-ish MB/sec. when the disk is empty). I have a bunch of MKV movies on there and was using my BluRay player and DLNA to stream for over a month just fine. Since upgrading to 6.1.5, all that went to H3LL. The nas does work for a while, but then freezes and hangs - needing to unplug the power to reboot.
Due to a (stupid) lock on the system, it won't allow me to downgrade back to 6.1.4 even though I can easily download the older firmware from NetGear. What gives on that?
Can anybody point me to a procedure to downgrade the firmware on the ReadyNas (102) series box? Thanks in advance!
It looks like if you have done a factory default after updating to 6.1.5 and then downgrade the volume can't be mounted. So they blocked downgrades to avoid users running into this issue.
If you get a copy of 6.1.4 and modify the firmware header to have a timestamp newer than that of 6.1.5 you should be able to downgrade.
hi, not a bug but a surprise.. I've added my 4th disk to rn104 with 6.1.5 and the rebuild speed seems to be higher than when I've added the 3rd disk with 6.1.4.
Did some more digging in the backup issue. (after a backup job is done, fvbackup-q keeps running at maximum processor load and this makes the nas really slow) jobs
The same problem exists in OS 6.1.6. When I killed fvbackup-q the processor load dropped to 10 % (from 98 %).
BTW, what command restarts fvbackup-q? /frontview/bin/fvbackup-q sais 'This program should be started by systemd'.
I have also been experiencing issues with large data transfers with 6.1.5. Sometimes to the point where I have to power off my RN104 in order to get it to respond. Earlier this week I deleted all of the data off of the unit and deleted all of the snapshots in preparation for testing later on. I also made two other changes. I turned off AV and changed the snapshot interval of my target share to once a week.
So last night before heading to bed I started a SSH session to monitor the tasks and I started a 4 TB file copy of nearly 3K files. I fully expected that I would login this morning and see that the process had stalled during the copy. I was pleasantly surprised to see that the copying was progressing well. I am averaging nearly 40 MB/s and so far no issues. While I don't have any firm conclusions to draw so far, I have to wonder if may the snapshot process might be part of the problem.
