ullibelgie

Das habe ich inzwischen auch gesehen. Ich hatte aber gehofft, daß ich mit dem Gebrauch von dem Bash Script von MGutt eben mehr lerne als nur Knöppe zu drücken. Womöglich mit der Folge, dass wenn ich wirklich mal einen restore machen muss die Software auch nicht richtig benutzt habe... naja - vielleicht bin ich ja doch zu dumm, das Bash script zu verstehen - dann wird es lucky backup werdem müssen. Unterschiede sind wohl vor allem darin zu suchen, wenn man bestimmte alte Backups aufbewahren will - dann muss man das mit luckyBackup eben manuell machen... habe mich aber damit noch nicht so beschäftigt. Jedenfalls Danke für den Hinweis - ist dann mein Rettungsanker, wenn es nix wird mit MGutts Script...

Ich kann doch am Ubuntu Rechner nicht mehr tun als in smb.conf unter [global] eintragen unix extensions = yes Ich habe nachgesehen - auch in Unraid ist im SMB setting eingetragen: unix extensions = yes Wenn das nicht korrekt ist: wie muss es dann richtig gemacht werden ? Und: Muss im smb.conf der Eintrag an einer ganz bestimmten Stelle gemacht werden, weil das ansonsten nicht funktioniert ?! Das Script auf dem Ubuntu Rechner funktioniert nicht, da die Verweisungspfade alle nicht mehr stimmen (z.B. der Notifikations) ausserdem bekam ich auch allerlei andere Fehlermeldungen - als quasi Laie was coding angeht, habe ich es dann mal gelassen...

Um meine Verwirrung komplett zu machen: Mein Testfile bei der Ausführung von ln vom Unraid-terminal war 650kB gross Frage: wie gross ist also Testfile und Linkfile (der vermeintliche Hardlink von Testfile) dann zusammen ?? Ausführung im Unraid Terminal mit cd im Zielverzeichnis stehend: du -d1 -h liefert 1.3MB (also kein Hardlink ?!?) Ausführung direkt auf dem Zielrechner im Terminal des zielverzeichnisses: du -d1 -h liefert 650kB (also doch Hardlink ??) Wat denn nu ?!

Ich kann nur als Anfänger der simpelen Logik folgen - für alles andere im Internet die Syntax suchen... also weitermachen: Ich hatte auf dem Ubuntu Rechner (Ziel für das Backup von Unraid was ich machen möchte) ja festgestellt, daß hardlinks funktionieren, wenn ich lokal mit Befehl 'ln' links setze. Nun ist aber die Frage, was passiert wenn ich das Zielverzeichnis von dem Backup-PC in Unraid mounte (unassigned devices plug-in) und dann im Terminal von Unraid die gleiche Procedure mache wie oben beschrieben - einziger Unterschied ist dann, dass der Befehl über SMB ausgeführt wird: Also im Terminal von Unraid eingeben: cd /mnt/remotes.... (Zielverzeichnis) Dann im Zielverzeichnis eingeben: ln testfile.pdf linkfile.pdf Kontrolle: ls Es ist jetzt nicht nur testfile.pdf im Ordner, sondern auch linkfile.pdf Jetzt checken nach Inode nummer: ls -i -h Die Inode nummern sind verschieden !! Das bedeutet doch, dass mit ln so keine Hardlinks geschrieben werden können über SMB von Unraid nach Ubuntu ! Was ist hier faul ? Oder ist das normal ? Es sieht hier so aus, als ob bei mir die Hardlinks erzeugen eben nur lokal geht aber nicht via SMB ! Doch irgendwas nicht richtig mit den Unix-extensions ? Wo muss ich was ändern in den Einstellungen ? Eigentlich wäre es das beste, das Script auf dem Zielrechner laufen zu lassen, wo auch geschrieben wird - aber dafür muss das Script neu geschrieben werden - das geht mit der Vorlage von MGutt leider gar nicht... Was tun ? Oder doch alles sein lassen und mit irgendeinem anderen Backuptool arbeiten ? Ich will aber was lernen und nicht nur Knöppe drücken...

noch vergessen: ls -i und ls-l gibt natürlich die Anzahl der Links auch mit 2 an...

So ich habe das jetzt mal gemacht: Ein File geschrieben auf den Zielrechner (Ubuntu) auf die gemountete Backup-HDD: 'testfile' (einfach ein paar Zeilen Text) Dann mit ln im Terminal einen Link, also im terminal eingegeben ln linkfile testfile" Es entsteht im Folder ein neues File 'linkfile' und ich habe jetzt also 2 files in dem Folder, nämlich testfile.txt und linkfile.txt Dann mit ls -i und ls -l festgestellt, das beide Files dieselbe Inode Nummer tragen, nämlich 11403266 Nochmals controlliert mit Eingabe im Terminal: find . -inum 11403266 Es wird ausgegeben: ./testfile ./linkfile Das beweist, das 'linkfile' auf dieselben Daten verweist wie 'testfile' - ich also mit ln einen hardlink schreiben kann auf meinem Ubuntu Rechner... Die Frage ist jetzt - wie gross ist der Folder "Link_Testen" in dem die beiden Files sind ! du -dl -h ergibt 16k Das ist weniger als 2x das Testfile, denn das testfile ist bereits 10k gross... Also kann Linkfile nur ein Hardlink sein (was zu beweisen war) Jetzt: Warum funktioniert das aber nicht mit dem Script ? Mir ist nicht klar, was mir die Testprocedure mit ln und ls Befehlen im Terminal auf dem Zielrechner bringen soll - ich weiss jetzt nur, das der Ubuntu Zielrechner Hardlinks kann.... Wie kann ich weiter vorgehen um das Script correkt zum laufen zu kriegen ? Danke!

Irritierend ist ja, daß das Script log am Ende sagt, das beim zweiten Backup der original Datei nichts übertragen und geschrieben wurden auf dem Ziel. Das wäre ja auch richtig, da an der Quelldatei nichts verändert wurde. Aber tatsächlich ist auf dem Ziel Ubuntu PC alles neu geschrieben worden. Habe nochmals überprüft: - beim Einfügen des script keine versehentlichen windows line-feeds, sondern correct Unix-LF benutzt - Am Zielrechner das smb.conf file enthält unter Global - Networking, die nicht auskommentierte Zeile unit extensions = yes - Im Terminal mit Befehl "testparm" überprüft, daß keine fundamentalen (Syntax-)Fehler im smb.conf stecken Also ich weiss leider nicht wo ich jetzt weiter suchen soll. Habe es nochmals ausprobiert - ohne Erfolg - immer jedes Backup genauso gross wie die Quelldatei...

Ich habe auf dem Zielrechner (Ubuntu 20.04LTS) im smb.conf controlliert: Unter Global Networking ist sehr wohl folgender Eintrag aktiv: Unit extensions = Yes Das kann es also nicht sein - leider. Wäre einfach gewesen... Es muss aber irgendwas anderes sein.

Hallo, leider war ich umständehalber eine zeitlang nicht mehr mit Unraid beschäftigt - es fehlte die Zeit und der Server stand ein paar Monate still. Jetzt habe ich mich wieder etwas eingearbeitet und will eine Backup-Lösung einrichten für die Unraid Daten und Systemfiles. Hierzu wollte ich eigentlich das Script von MGutt nutzen aber es will nicht so recht funktionieren. Folgendes habe ich getestet: Ein Testfolder mit einigen Dateien van ca 5Mb soll auf einen externen Linux PC (Ubuntu 20.04LTS) gesichert werden Die HDD vom Zielrechner ist mit dem Plugin 'unassigned devices' in Unraid gemounted und die URL im Backup Scipt vers. 0.6 auch als Ziel angegeben Ich führe das Script auf Unraid im Hintergrund laufend aus mit dem Script Plugin 'User scripts' aus - das funktioniert prima und die Daten werden auch auf der HDD des Zielrechners geschrieben. So weit alles gut - aber: Wenn ich das script nochmal ausführe ohne den Quellordner irgendwie geändert zu haben, wird wieder alles in voller Grösse geschrieben und die frisch formatierte ext4 HDD hat jetzt doppelt so viel Speicher beschrieben wie der Quellordner gross ist (also kein incrementelles Backup) Wenn ich das script dann 5x ausführe immer mit dem gleichen Ordner ohne Anderungen, kann ich mit du -d1 -h /url Zielordner | sort -k2 genau sehen, das eben 5x die 5Mb vom Test-Quellordner geschrieben sind und die neue Platte eben 25Mb neue Daten hat. Das scheint mir nicht zu sein, wie es sein sollte ! Zur Kontrolle habe ich mal mit rsync manuell: rsync -avh "quellordner" "zielordner" mehrere Male ausgeführt mit dem korrekten Resultat, dass der Ordner nur einmal über das Netzwerk auf den Linux-Rechner gespielt wird und die Daten nicht mehrfach in voller Grösse übertragen und geschrieben werden (Dupes!) Allerdings: Wenn ich mit dem Script von MGutt innerhalb des Unraid servers auf einen Zielordner ein "Backup" machen lasse und eben nicht über das Netzwerk (einfach von einem Share auf einen anderen Share in Unraid), dann funktioniert die Sache und der Folder wird nur einmal in voller Grösse geschrieben. Man sieht das nur das erste Backup die Originalgrösse hat und alle anderen Backups viel kleiner sind. (so wäre es korrekt!) Was mir auch aufgefallen ist bei der Ubertragung des 2ten.3ten, 4ten Backups (immer mit demselben Ordner uber das Netzwerk): Im Log wird ab dem 2ten Backup gesagt das nichts übertragen/geschrieben wurde, aber tatsächlich waren alle Daten doch in voller Grösse doppelt und dreifach geschrieben worden - es scheint also, als ob das Script log nicht übereinstimmt mit der Realität. Was kann hier die Ursache sein - was müsste ich evtl mal uberprüfen um das Script doch richtig zum Laufen zu bringen um von Unraid auf ext4 formatierte Platten nach Ubuntu zu sichern. Leider habe ich es nicht fertiggebracht die HDD in xfs unter Ubuntu zu formatieren - hier ist vielleicht die Ursache im anderen Filesystem zu suchen ? Hat schon mal jemand wirklich getestet ob das Script läuft auf Zielmedien von ext4 Platten - hier sollten Hardlinks eigentlich unterstützt werden, aber ich habe inzwischen meine Zweifel... Oder muss ich in Samba auf dem Zielrechner irgendwas einstellen was bisher fehlt (.conf file) Vielen Dank für ein paar gute Tips zu dem Script.

Meine Ubuntu Version is 20.04 LTS

"But if you did the format before assigning it to the array, then the format you did, though pointless, wouldn't have been a problem. I say pointless because rebuild is going to overwrite the entire disk, including any format you did." Thanks for explanation - I was not aware, that there is no need to format the disk.... but I am just a stupid user of computer applications until I started with Unraid a few weeks ago. I am depending on people like you who explain to me how things work and I try to read as much as possible about it... "So, if you format a disk in the array and then rebuild it from parity, the rebuild can only result in an empty filesystem." This is clear to me now, but it is not what I have done - the disks were formatted before they were assigned to the Array - useless though... But thanks for the warning ! "Also note that if you pre-clear a disk, then format it as you did, it is no longer clear. So if you add that disk to a new slot in the array, Unraid must clear it again so parity remains valid." Another reason not to format a disk in the replacement process So you can see, that even there is a extensive wiki available, which I at least have read 10times, you still can misunderstand a lot with no IT-background at all... we call it learning...;-) I did not expect my server to last longer than one month.... I almost reached it, before it breaks... Now it is time to do it again, I think - I still have the old data-disk, which contains the files of Disk 1, which I now moved partly to lost&found... so I can recover it, I hope

Clean re-install: I am using Unraid as a simple NAS - just a fileserver plus two applications: Paperless-NG and Calibre Recently I had to repair XFS file system on one of my Data-disks. Result is, that 360Gb of data is moved in the lost&found folder. As this is from moved from all shares (incl. Appdata, system, etc...) to the lost and found folder, I am dependent on this folder and cannot this 360GB of mess (partly unreadable) So I want to make a clean re-install without a need for a 360GB Lost & Found Erase all shares and build them new - possibly by uploading 100000 files or more with rsync from offline data storage... Do I need to erase and reformat the disks as well ? I am just looking for a safe procedure to erase the large lost & found-folder

I followed the procedure of the Unraid wiki for taking out disks to replace them with bigger ones. Every new disk needs to be formatted - that is, when Unraid sees the new hardware for the first time and place it in the unassigned disk plug-in. Here I pre-cleared the new disks (stress test for 2days) then formatted them in XFS After that assigned them in the disk array, so at that moment the rebuild process started and finally finished with zero errors... Then I switched off the Server in the evening to switch it on next morning with the new Data disk being unmountable After XFS_Check and XFS_repair, I end up with half of the data moved from Data Disk 1 to Lost & Found folder The problem is that for example files which have been before in "Audio" share, have been moved to "Lost & Found" and are not in the Audio share anymore... In total this in total 360Gb moved from all shares (incl system, AppData....) to lost and found and many are unreadable... I don't know how to correct this -- rather than build a new server ... copy & paste for weeks from offline data files.... no real server backups, just the original data at it original place had not (yet) been erased, as the server is only about 4weeks old...

I recently had a lot of hardware problems, which made xfs_filesystem repairs necessary. So I end up with hundreds of GB Lost & Found file/share, with the moved data, due to the failures. I think the problems are because my server is rather old hardware and the timer in disk settings for waiting before shutdown, was improperly short set to only 90sec. Although I am not running any VM's and normally close dockers manually and stop the disk array manually before pushing the shutdown button in Unraid web-gui, it may be not shutdown correctly and therefore caused the problems... I now consider a clean new install of my total Unraid server. I have recent backups of: - USB -stick - AppData folder - external Paperless-NG folder consisting of all documents for this app - Ebooks with Calibre database - all other data is still available offline as well So how to do a clean reinstall ? The unraid Wiki explains the steps for 'getting started'.... but I want to 'get re-started' - that could be a difference as the disks are not empty Also: How do I manage the Unraid OS plus license ? Should I start the USB stick with the .zip backup instead of the clean Unraid OS software ? Please advice the best way for a clean re-install of the server I do not want to keep the mess, which has occurred with 360Gb of Data moved to lost and found with lots of data even unreadable Many thanks...

I think I know the reason for the XFS - file system problems: My machine is a very old hardware and slow. However the disk settings for wait until shutdown is only 90sec. It could be, that this timing is too short to guarantee a clean shutdown under normal circumstances, because the server hardware is old and rather slow... So I increased the timer now to 600sec to be save and to prevent a unclean shutdown... I am considering to rebuild the total server with a new clean install - all data I have offline ...

Nachkontrolliert mit dem angegebenem Befehl - alle Backups sind immer gleich gross und so gross wie das erste Backup...wie vermutet Was ist hier bloss faul mit meinen Einstellungen ?

"Wie hast du das verifiziert?" Am Ubuntu client muss ich ja im Terminalfenster das Backup-script aufrufen und ausführen - bei mir heisst das dann 'unraid.sh' bei Eingabe im Terminalfenster von Ubuntu gebe ich also ein: ./unraid.sh Das script fragt dann seine incremental file list an beim Server und dann sehe ich alle files, wie sie im Terminal Fenster nach und nach kopiert werden und dabei durchscrollen - das dauert dann so ca 15min fur die 50Gb Aber jedes Mal wenn ich das Script auf dem Ubuntu client neu aufrufe (ohne bei den Quelldateien irgendwas zu ändern) dauert es wieder die 15min mit dem durchscrollen aller FIles, die kopiert werden, aber nicht geändert wurden. Ich würde erwarten, dass das Script sagt - keine neuen Files - dann brauche ich auch nicht zu kopieren - genauso wie es beim manuellen ausführen von rsync passiert (s.u.) Denn mache ich den Kopier/Backupvorgang mit rsync manuell mit: rsync -avh "source-folder" "destination-folder" dann scrollt die File-liste nur einmal (beim ersten mal!) durch das Terminalfenster. Führe ich dann denselben Befehl mit denselben Quell- und Zielfoldern noch einmal aus, scrollt uberhaupt nix mehr durch, da ja alle Files bereits im Zielordner vorhanden sind. Ich dachte, daß müsste bei einem korrekten incrementellen Backup mit dem Script genauso sein - dass eben nicht die Files die alle kopiert werden wieder 15min lang durch das Terminalfenster scrollen und schliesslich mit 15867 files kopiert zum Schluss kommen... Inzwischen habe ich versucht Abhilfe zu schaffen, durch im /etc/samba/smb.conf file in Ubuntu unter [global] die Zeile unix extensions = yes einzufügen mit anschliessendem restart des samba service auf dem Ubuntu client... Keine Anderung... Wohlgemerkt: Ubuntu holt mit nur Lese-Rechten die Files vom Unraid server via Samba ab... Hierzu habe ich alle benötigten Folder vom Unraid Server im Ubuntu client gemounted und die Quell und Zielfolder angepasst. Das ist ja etwas anderes als ein lokales Backup auf dem Unraid server zu machen , wo Quell und Zielordner auf demselben Server liegen...

I still have the old drive and unchanged since I have taken it out. This disk had a few read errors before but was not disabled. I never had to xfs_repair the old disk.

tja, mir scheint auch langsam das es wohl ein Hardware Problem gibt mit den USB porten Ich habe jetzt die XFS formatierte USB platte lokal am Ubuntu PC angeschlossen - das funktioniert tadellos. Dein Script habe ich lokal am Ubuntu PC aufgerufen und hole mit mit read-only Rechten die Daten ab, die ich vom Unraid server auf der USB Platte sichern möchte - funktioniert prima und ohne Unterbrechungen (ca 50Gb Daten) Allerdings habe ich ein Problem: Wenn ich das Script nach erfolgreichem Backup auf dem Ubuntu nochmals ausführe , dann werden alle Daten offenbar noch einmal kopiert, obgleich die Daten dieselben sind. Habe ich eine Einstellung vergessen, die verhindert, dass incremental backups erstellt werden ? Die Unix Extensions habe ich in der Samba Einstellung auf Unraid herausgenommen, da das bei Ausführung des Scripts auf dem Ubuntu client doch nicht nötig ist - oder hatte ich das verkehrt verstanden ?

I use XFS file system for all drives To clearify: "If you are happy to lose the 320GB that was put there by the repair process then you can simply delete it and remove the share. " What does it mean ? Of coarse I do not want to loose data, but I also do not want to store data twice. The data should be in the original folders, but not somewhere in lost and found. So what I need to know: Has the repair process as a result of the repaired file system moved the data from it's original folder to lost and found ? As the lost & found file contains 1926 objects, 1874 directories and 52 files it would be a very cumbersome process to find out... What would you do ?

I recently changed my Parity disk for a bigger one and after that changed one of my data disks to a bigger one as well. I followed the guide in the Unraid wiki for doing that and although it took a very long time (3 days and nights) all went find with no errors. So at the very end, when everything was finished fine, I switched off the server safely - I stopped the array followed by the shutdown button in Unraid. When I wanted to restart the server the next morning, my newly installed (bigger) data disk was unmountable, but not disabled. Pre-clearing, formatting and rebuild process was without any error however before. I was wondering how that can happen....!?! So finally after reading a lot in forum and Unraid wiki documents, and still not understanding why the brand new HDD is unmountable, I decided to check the filesystem and finally run the repair routine... Fortunately the new disk with all the data rebuilt from the old Data-disk now was mountable again and it seems, that the system runs without faults... However what concerns me is, that I now have a folder of 360GB on this newly installed disk (lost & found) as well as a new Share with the same name. This is to me really a waste of HD-space. It was not my intention to install a bigger data-disk just to waste the more space with a file, which I don't want... It is annoying to have a share 'lost & found', which I don't want, but which is bigger than most other folders... Can I delete it ? Or at least delete all content of it ? Should I install the old disk again and go to the total disk change procedure once again to get rid of that large lost & found folder ? I really do not want the lost & found folder occupy most of the additional space of my new hard disk - the exchange of data disk would be useless then. What is the experts advice ?

Ich habe heute nach dem Hardware upgrade (neue Parity disk und eine der Data-disks erneuert) nochmal probiert ob ich eine der Lacie externen USB platten nutzen kann fuer Backups mit dem rsync script... Leider negativ, wie schon eher berichtet ! Die 1Tb Lacie USB ist zwar schliesslich doch mit XFS formatierbar gewesen, aber das Backup wurde so nach 2-3Gb abgebrochen. Syslog: (sdb ist die USB platte) Was soll ich hiermit jetzt machen - bisher hat jede USB Disk aufgegeben nach ein paar GB schreiben... Aug 16 21:00:24 Tower emhttpd: cmd: /usr/local/emhttp/plugins/user.scripts/showLog.php MGutt_Fotos naar Backup_schijf 20 Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 25 88 00 00 f0 00 Aug 16 21:00:49 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484137864 op 0x1:(WRITE) flags 0x104000 phys_seg 8 prio class 0 Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 26 78 00 00 f0 00 Aug 16 21:00:49 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484138104 op 0x1:(WRITE) flags 0x104000 phys_seg 8 prio class 0 Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 27 68 00 00 f0 00 Aug 16 21:00:49 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484138344 op 0x1:(WRITE) flags 0x104000 phys_seg 8 prio class 0 Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 28 58 00 00 f0 00 Aug 16 21:00:49 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484138584 op 0x1:(WRITE) flags 0x104000 phys_seg 9 prio class 0 Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 29 48 00 00 f0 00 Aug 16 21:00:49 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484138824 op 0x1:(WRITE) flags 0x104000 phys_seg 8 prio class 0 Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 2a 38 00 00 f0 00 Aug 16 21:00:49 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484139064 op 0x1:(WRITE) flags 0x104000 phys_seg 10 prio class 0 Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:49 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 2b 28 00 00 f0 00 Aug 16 21:00:49 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484139304 op 0x1:(WRITE) flags 0x104000 phys_seg 8 prio class 0 Aug 16 21:00:50 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:50 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 2c 18 00 00 f0 00 Aug 16 21:00:50 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484139544 op 0x1:(WRITE) flags 0x104000 phys_seg 9 prio class 0 Aug 16 21:00:50 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:50 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 2d 08 00 00 f0 00 Aug 16 21:00:50 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484139784 op 0x1:(WRITE) flags 0x104000 phys_seg 8 prio class 0 Aug 16 21:00:50 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Aug 16 21:00:50 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x2a 2a 00 58 76 2d f8 00 00 f0 00 Aug 16 21:00:50 Tower kernel: blk_update_request: I/O error, dev sdb, sector 1484140024 op 0x1:(WRITE) flags 0x104000 phys_seg 21 prio class 0 Aug 16 21:00:52 Tower kernel: sdb1: writeback error on inode 1628217011, offset 167772160, sector 1484121944 Aug 16 21:00:52 Tower kernel: XFS (sdb1): log I/O error -5 Aug 16 21:00:52 Tower kernel: XFS (sdb1): xfs_do_force_shutdown(0x2) called from line 1196 of file fs/xfs/xfs_log.c. Return address = 00000000fe4bac91 Aug 16 21:00:52 Tower kernel: XFS (sdb1): Log I/O Error Detected. Shutting down filesystem Aug 16 21:00:52 Tower kernel: XFS (sdb1): Please unmount the filesystem and rectify the problem(s) Aug 16 21:00:52 Tower kernel: XFS (sdb1): log I/O error -5 Aug 16 21:00:52 Tower kernel: XFS (sdb1): log I/O error -5 Aug 16 21:00:52 Tower kernel: XFS (sdb1): log I/O error -5

Hello - I want to follow this concept, but from an Ubuntu client (instead of Windows) However how do I do this ? Create additional user... should be ok created additional samba-user - should be also ok However finally I cannot mount the ubuntu ext4 disk in unassigned devices plug in It says permission denied - does it NEED write access ? Because when I grant full write access there is no problem....

Telefons sind für später - erstmal an den Rechner vom Gebraucher anschliessen und z.B. Fotos auf den PC spielen - das wird dann in den Folder gelegt, der einmal täglich mit rsync auf Unraid aufgespielt wird... Ich muss erstmal mit den einfachsten Dingen vertraut werden und klarkommen - wenn das richtig implementiert ist und ich auch verstanden habe warum und wieso, kann ich daran denken Dinge eleganter zu lösen... alter Mann kein D-zug...lol Danke für die Beispiele - das schaue ich mir an und probier es aus...

Hallo Joerg, ja, natürlich ist der Server ur-alt... aber wie gesagt, momentan beschäftigt mit unclear und leergeräumtem Array... wenn die neue Parity Seagate Exos und Data disk drin sind, kann ich wieder hochfahren und die USB Lacie Platten nochmal untersuchen... Marc, kann man das Syslog von gestern doch irgendwo sehen, wenn man letzte Nacht den Server ausgeschaltet hat ? Ich dachte das Log wäre weg, bei reboot... Wird wohl morgen werden, denn muss ja auch noch formatieren und das Array rebuilden - erst Parity (mit der alten Data-disk) dann die Datadisk wechseln, wenn ich das im Unraid Wiki richtig verstanden habe...