A long list? On a fresh install without any active services there shouldn't be any active process blocking the raid. Did you make sure that no service is active? Deactivate smb/cifs or whatever is on the list.
Beiträge von datadigger
-
-
Did you play with shares, any services activated?
All from the command line:
Make sure the raid is not mounted: umount -l /dev/md127
Deactivate the raid mdadm --stop --force /dev/md127Does that work or do you receive the error message again?
If yes, there is still a process running on the raid and blocks it. Run fuser -vm /dev/md127 to see which process is still active.If no, the raid should be gone. Remember to wipe the former raid disks before you can use them in a raid again.
-
Somehow.
Yes they are great servers, reliable and powerful. I have some T410 and T420 among my weaponry at work, but to be honest: Even if a T410 consumes a little less than 200 watt what is not that much for a real server system I wouldn't have one at home and pay the power bill.
-
I guess there are different approaches to achieve a site-to-site data sync'ing. Call me somehow overcautious, but I never rely on third-party services when I have to connect two sites for exchanging data.
My favorite is to build a secured site-to-site VPN and then let a rsync job do the data sync. But such a VPN requires appropriate router hardware with encryption levels like AES-256, preshared keys and so on. -
An iDrac 6 card, on which Dell do you run your NAS, should be a gen11 box like a R510 or T410?
-
So this is your new system, right? To me it looks like you are a little confused concerning the file system tab. What the screenshot shows is a root fs disk (sdc with 226gig , like you've described in your first post), your system disk. There is nothing to manage, mount or delete with it, just leave it as it is.
The raid tab shows a degraded raid and in your log file mdmstatus tells that this raid consists of only one disk (sda), so the mirror is broken. You can rebuild the raid using mdm commands from the command line or delete it, wipe the disks and build a new mirror.And that is a lesson conecerning your question what to do if a system or its hardware fails and you want to move the disk to another system keeping the stored data. Mdadm writes it's configs to the disks belonging to a raid, so you can move the disks in case of a hardware failure or replacement without loosing data. I've done that before a lot of times, the last time I moved a raid5 consisting of five 2TB drives to a totally different hardware and after raising a new OMV installation the "old" raid was perfectly discovered.
If you want to keep the data then have to look into the /media/<UUID-of-the-raid>/ folder, the "old" shares are still there. Just create new shares with the same names like the old ones, make them available under SMB/Cifs and everything is in place like it was before.Now in your system mdadm has found the old mirror, but the mirror partner was not detected. Did you made any changes to the other disk (sdb), new partition or so?
-
The sequence of the disks doesn't matter as long as the system respective the boot loader finds the root fs and that seems to work.
What does that mean, the raid doesn't look right? Which kind of raid, a mirror?
Do you want to keep the data on sda and sdb? Are all the disks listed correctly under physical disks?
-
Will that come to an end or does it loop forever? I've seen similar messages on a system with a defective RAM stick.
-
You might see some speed differences on some things, due to the speed differences between the USB bus and the normal internal SATA bus.
There are of course differences, but you will reach the limitations of a single gigabit network link long before the throughput of an USB3 or SATA link reach their limits. So that doesn't make a difference in terms of usability of a NAS. -
Der Neustart ist mehr wie ein hartes Auschalten
Für einen kurzen Moment ist alles ruhig, Lüfter und Platten drehen sich nicht mehr.
Dann piept es kurz und alles fährt wieder hoch.
Hört sich für mich nach einem Problem mit der Hardware an. Mögliche Ursachen können defekter Ram sein, Probleme mit dem Netzteil oder Mainboard oder der Kiste wird es zu warm. Ist der CPU-Kühler vielleicht zugesetzt?
Wie sind die 4GB Ram denn organisiert, ist das ein Riegel oder sind das zwei? Wenn es zwei sind, dann nimm mal einen raus und schau, ob das wieder auftritt und dann mal mit dem anderen Probieren.
Stresstest ist natürlich auch gut, wenn die Kiste dabei aber überraschend bootet, dann kann man auch nicht so genau sagen was es nun ist. Im Prinzip hilft bei solchen Auswirkungen meist nur durchtauschen.
Wenn es auch mit anderen Ram-Riegeln und anderem Netzteil auftritt, dann bleibt nur noch das Board übrig. Defekte CPU hatte ich auch schon, aber das ist ziemlich selten.Ein Update auf die 1.x Version ist natürlich empfehlenswert, aber ich fürchte dass das Problem damit nicht behoben sein wird.
-
Aha. And if discard doesn't appear does that mean the SSD wasn't properly detected during reboot?
-
That looks as an usual fstab to me and I do not know if you can tell by the entries if a disk is a SSD or not. That doesn't make a difference for the fstab entries.
You can check with cat /sys/block/sda/queue/rotational if the system sees the disk as a spinning one or as a SSD. If you get "0" it is a SSD, "1" means it is a spinning disk. -
In addition I've performed "hdparm -t dev/sd*" and:
- WD RED Timing buffered.....: 113MB/s
- hdd for os Timing buffered....: around 40MB/s - similar to speed in CrystalDisk and SMB sharing..???
Please post the full output of the hdparm test, there must follow a value behind this - something which is calculated during the test period of about three seconds. -
Was bedeutet in diesem Fall denn "neu starten"? Abrupter reboot als wenn jemand den Resetknopf gedrückt hat oder Herunterfahren und Neustart?
-
You have to add the env variable at default location for omv OMV_PROFTPD_DEFAULTROOT="~" and enable/disable or make a change in the webUI and omv reloads and rewrites the proftpd.conf.
Sorry, I forgot to tell that it is working now. I forgot to use the double quotation marks...
-
You should create a feature request at http://bugtracker.openmediavault.org/
And all your attempts to limit the transfer rates didn't work? Well, I made the experience that proftp running as a plugin on OMV is a litte fussy if you want to change the standard settings.
For example, if you enter a command like DefaultRoot in the extra options of the plugin, this command is saved to the proftpd.conf file, but the server doesn't use it. Why? After checking the proftpd.conf I saw that the DefaultRoot direcctive appears twice.... the first one is the standard setting (For me this seems to be hardcoded) "DefaultRoot /srv/ftp" and some lines below my command "DefaultRoot ~", but the second one seems to be ignored.
The only way to tell proftpd that it should use the tilde for leading users to their home dirs is to enter a line in the OMV default config file at /etc/default/openmediavault using the correct syntax and then it works.To make a long story short, did you try to use the correct settings for limiting the transfer rates in the default file? I would enter a line like OMV_PROFTPD_TRANSFERRATE="RETR 20.0", run "omv-mkconfig proftpd" and "service proftpd restart" from the CLI.
If you then enter some limitations for the number of connections, say max. 5 clients and max. 2 connections per client this should end up in a max. transfer rate of 200kb overall. Give it a shot and tell if that works. -
Yes, please. I tried that by inserting the command in the web-gui under ftp where you can insert extra options and by inserting it in the openmediavault file as described above. Either way didn't work.
Commands inserted in the extra options are directly transferred to the proftp.conf file. I have "ServerIdent Off" in the extra options and this can be found in the conf-file, too. -
You can define a share to be a home folder for all OMV interface users.
That's what I already had defined before I started to find a way to chroot them.Ok. A little bit more of digging, indicates that instead of whole path you can use ~ at DefaultChroot and the users will be chrooted into their home dirs.
Did you try that on your system and it works? Interesting... on mine it didn't. The simple use of "DefaultRoot ~" leads the users to /srv/ftp. -
Hmmm.... I didn't mention permissions, they are set correctly for each home directory and when a user connects via FTP into his home dir he can up- and download and so on.
I am interested to know if there is another way to lead every user automatically into his home dir other than using %u with the DefaultRoot directive without the need to step forward into the right directory.
-
Yesterday I tried to set up a FTP server for internal use. We have a lot of mobile devices around in the 24.000 pallets warehouse, they are all connected via WLAN and some of them are of different make. We are running a self-developed app to connect to an internal SQL server and they sometimes need an update, but they have to pick it using different accounts. So I need to jail them into their own directory.
That let me ripping off the small amout of remaining hairs until I found a way how to do that and now I'm wondering if anybody has made it by using another way.
At first I tried the "DefaultRoot ~" directive in the parameter window inside the FTP server config, but that did not work. The user always ended up in the /srv/ftp directory (The logfile shows that) even if I activate the use of home directories under user/settings. These home dirs will be created when I add a new user, but proftp seems to ignore that (Or doesn't know about that, possibly the system-wide $HOME setting will not change).
I added a setting in /etc/default/openmediavault which reads OMV_PROFTPD_DEFAULTROOT="/media/<UUID-OF-RAID>/<sharename>/%u and that works. But I've read some rumors that future versions of proftpd may not support variables like "%u" anymore.Any other ways to do that?