642

It's OK. Thanks a lot.

Hello, I've made a change, update a 3TB drive to a 6TB. Now I can see that there is a lot or errors in syslog. Every two seconds : Sep 13 01:17:26 Tower root: error: plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Sep 13 01:17:28 Tower root: error: plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Sep 13 01:17:30 Tower root: error: plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Sep 13 01:17:32 Tower root: error: plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Sep 13 01:17:34 Tower root: error: plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token Sep 13 01:17:36 Tower root: error: plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token etc: ABsolutely no idea of what is going on. Can you please help, thanks tower-syslog-20190913-0107.zip

The problem is that I haven't a 'linux' system, but only a PuTTY access. And I didn't find a way to write (write with the keyboard, so simple as that) the special character \251 that appear one time as a "¹" (upperscore 1), somtime as an empty square, sometime as a tilde something. And this is only one character I've used, there are certainly others. How may I have a "clean" interface, on which I can write what I'm searching clearly. "linux find filenames with special characters" "remove special characters from filename linux" Already tried some tricks from those results 8 months ago, but without any success. I'm not a linux's user, either. It's not my goal.

Hello, still stuck with the problem, those files are always missing from the directories, but in fact still on the server physically. I want to have a solution, and a way to find all the files with the character \251 on it's name to correct those files, not by looking on all the directories one by one (more than 5000). I may use the "script" on one disk after another, or anyway. I'm using PuTTY 0.60 on a windows system. Not see anything about that on the recommendation when upgrading. On my pov, there is only one system using it, and it's windows.

In fact, the files are diplayed as : AE11\251.avi AE13\251.avi .... in fact the character \251 is indeed the character used for entering the "¹" (upperscore 1). If I want to correct my problem, I have to find all the files containing a character \251 and swap it for something else, like a space \032 or whatever, and this for all the directory of the disk. Is it something easy? Anyway, the problem is strange : if I currently name a file with a "¹" into the name in windows, the file look correctly either inunraid (mc) or in windows. If I make a copy of the file with mc, the copy seems perfecly fine. It seems that is on the step from reiserfs to xfs that there is a problem.

OK. I've changed nine 4TB disk from reiserfs to xfs. It was done on a 6.3.5 unraid system, completely offline - not connected whatsoever. I've made the copy with midnight commander, locally, with a keyboard and a screen. Everything seems fine, at first. After a while I discover that some files are missing. In fact they doesn't appear on windows. For example I can see only 9 files on a directoty with 65 files (from AE01 to AE65, easy). WTF? In fact, the problem is not as catastrophic as it seems at first, the files are still on the hdd but not visible. I've access to tower with putty, and using mc I can see all the files, including the missing one. It seems that there is an issue with the name, I've used some special characters like "¹" (upperscore 1) on some files, and those files doesn't appear anymore on windows. Inside midnight commander, the files appear with the complete name, length, date, etc. However, the character "¹" (upperscore 1) was replaced by a character "empty square" in each files that doesn't appear in windows. It was probably because of the change from reiserfs to xfs. With mc, the cure is easy, just use <shift><F6> to rename the file, going to the "empty square" character, replace it by another one and voila, the file directly appear back in windows. If I browse through the same directory with the web page of unraid server pro, index of the disk , the files are there but without any name at all, the line is empty starting with a correct icon depending of the extension (even if there is no name or extension at all), no name and no extension, the correct size and date. I don't know if ther is no other files missing with another special character in the name (like "¢", or "©" etc) I don't know how to look inside 5203 directories for the 361902 files of 31,8 TB where are the "bad named" files.

I've made memtest. I have check two banks of memory, single, by two, ganged, unganged, interleaved or not, under clocked or not : not a hitch for at least 3 passes, no error. I've retry the server without unmenu plugin, no dircache, nothing. On the go file, one line active only : "/usr/local/sbin/emhttp &" Always the same process, start the array, start parity check (usual stuff on syslog). After a while between 2 mins to 15 mins, a bunch of red lines starting with "Tower kernel: Pid: 1484, comm: unraidd Tainted: G O 3.9.11p-unRAID #5 (Errors)". Then those red lines will repeat every 2 to 15 mins, the network response very slow. In the meanwhile the parity check will continue at 30MB/s approximatively. I've disabled "Cool'nQuiet" and "AMD CE1" support in the Bios. ... OK : FOUND I've found the "core" of the problem if not the solution. I've disabled three cores out of 4 cores of the Athlon IIX4, and everything seems fine. Then I've eventually disabled only the 4th one and it seems sufficient. I don't know why but just doing a parity check, with all the cores I've errors in the syslog (see above) and a speed of around 20-35MB/s. With the 4th core disabled (I've not checked for the 2nd only or the 3rd only), there is no error like above in the syslog while parity checking, and it's running at 60-75MB/s. If someone comes with an idea (the Athlon is dying?), Thanks.

Thanks trurl, you're right. Stopped parity check, reboot server, then restart and again restart parity check. Every 1-10 min, a bunch of red lines with "Tower kernel: Pid: 1484, comm: unraidd Tainted: G O 3.9.11p-unRAID #5 (Errors)" In fact recently I've done nothing more than moving a lot of files in and out of the server. syslog-2018-01-29 (after reboot check parity 4gb) red bunch of lines every 5-10min.txt

I'm currently doing a parity check on my unraid 5.0.5 NAS. Very slow, about 20MB/s, it's unusual. But on the main page, nothing special. However on the syslog, everything is red, here is a sample : Don't know what to do: stop unraid, stop parity check, from where those eroors are coming?

Good advice, I've already been asking myself what the hell is going on, it's just to delete something. Thanks.

OK if I'm correct, I will assign the disk from the unraid 5.0.5 after the "New Config" step. So the steps are : power on - stop array - Tools, New Config with Retain All - apply - reset - assign the new disks - start the array Thanks As I'm gluing some parts from an unraid 5.0.5 I'm wondering if I may copy some data more quickly by another tricky astuce. From an unraid 5.0.5, I want to stop it and remove some hard disks full of data. Then I will put those hard disks into the unraid 6 server and copy the data from those rfs disks to an xfs disk. After the copy I will remove the disks to put them back into the original unraid 5.0.5. Of course in the meanwhile the unraid 5.0.5 should be off. After all the process in which the content of the disks from the 5.0.5 stay as it, should the parity be lost? I'm wondering because at each start the unraid seems to write something on every data disk (what? why? where?) and so I'm thinking that the parity should be incorrect. And as I don't know what was written on the disks at each start, is it a good idea to take a disk from a v5 unraid, put it into another v6 unraid, copy the data from the disk and then putting it back at the previous place into the v5 unraid? No problem to install back the disk into a v5.0.5 unraid after a journey into a v6 one? Thanks

Thanks and how simple! If I correctly understand, I'll power off the current v6 server, physically install and connect the old disks from v5.0.5, then power on the server. The server should be stopped, then I'll assign the new disks to the devices, and finally Tools -> New Config while retaining the parity and data disks (or not ?). After that the parity will be re-calculated as if the data disks are known as good. And voilà. So so No. I definetely doesn't understand the "retain current configuration" "to populate the desired disk slots after the array has been reset". What will that mean "after the array has been reset", what is the so called "reset" In my case I've already assign (populate?) the slots so the config is the one I see on the main page. Have I to retain something? I know that after the integration I should take a while to empty the old disks one by one, reformat them in xfs, then re-import the datas back.

I'm currently completely re-designing my unraid server. So I start from scratch a new server with unraid v6.3.5 and some 8TB disks, and it will be ready in a while. After that, I want to integrate some data disks already in my old unraid v5.0.5 pro directly onto the v6 server. The v5.0.5 is running well. Those hard disks are eventually to be part of the new server. I want to avoid copy the data back and for if possible. Question 1 : what should I do to add a 4TB disk formatted (GPT: 4k-aligned, reiserfs) and full of data from v5.0.5 to another server running v6.0.35 without erasing those data? Question 2 : may I add more than one disk at a time, I have 9 disks to integrate so to do this in one go is a big plus. Before the integration, the parity on both server will be checked. Of course I know I will be without parity for a while when doing the integration. Thanks I've made some research to see if that question was already posted before, but I didn't find the forum explaining of how to efficiently search something on limetech forum.

Hello, Are those HDDs : Seagate Enterprise 8TB SAS 12 a good choice to use with Unraid 5.0.5 pro? Thanks for help

OK, original old syslog attached. I've never looked at it, I don't understand those syslog and the colours are lost so it's difficult to see what's matter. Anyway, the system boot in april 14. There was a bunch of errors in may, 10-12 and apparently I didn't notice thoses. Some more in june, 21. For some reason, I look at main status in july and, after grabbing the syslog and a picture of the main screen, assigned the failed HDD for another one already connected inside the server and I've removed the "bad" HDD some days after the swap. Now I've put the "bad" HDD in the same place as before, launch preclear on it and it seems that everything look fine. Maybe an issue with power, sata cable... Thanks anyway. syslog-2015-07-23.zip

Hello, Some months ago, one of my 4TB HDD seems defect on my unraid 5.0.5. Red ball, 128 errors, unraid server has stopped this HDD. So I've simply swapped this HDD for another new one, and I should send this HDD back to Seagate for fix it. Some days after, I've put this HDD on the original external USB box, and I've check the HDD with the seagate program before sending it on guarantee. No problem found, the HDD seems perfectly healthy. I've forget the HDD some months on my desk. Now I've test the HDD with preclear, and the results doesn't seems bad. What is wrong? Attachments : - Main unraid capture, with the HDD fail (FYVB). - preclear finish report for the same HDD (FYVB), but 4 months after. Seems healthy, no? Thanks preclear_finish__Z300FYVB_2015-11-10.txt

Today I simply want to change my shares configuration, and after some try and fail, I eventually see that I cannot change this at all, all parameters stay rock solid. So I look at the syslog and see 6 unusuals errors (in red) with three different kind of. 1. fat_get_cluster 2. secrets.tdb 3. super.dat I'm pretty sure all those errors are bounded (no configuration change, etc..) and coming from the fat_get_cluster problem, of the FAT-fs (sdf1), and I think it's from the flash. I've already save the key, but what should I do to be safe? Power down unraid, take the key and format it as new, put back everything (w or w/o super.dat and secrets.tdb ?) Thanks for some help

The standard one -> "Utils", "Upgrade Utilities", "New Permissions".

Done by the command line successfully (elapsed time 03:59:39). Now the problems seems to be cleared. For some reason, with the web GUI, the process is systematically stopped after a while at the 4th disk. Nevertheless, thanks for the help,...

Is it possible to have some clue about the script "New Permissions" that seems to be the root of the problem? Thanks

Yes of course. At the bottom of the window, there is a button "Close" that came at the end of the job. In the beginning I had the same thought as you. But now?

It won't hurt anything. It is just going through your folders/files and doing chmod and chown on them. Been a while since I used it. I think it launches a new window that you have to keep open until it finishes. Thanks for some lights Re-Done. I've run the script called "New Permissions" in the "Upgrade Utilities". In fact something change. It seems that the solution is to find in this direction. Some directories in which there was no possibilities to delete/rename a file seems to have a standard behaviour now. No problem to rename/delete a file after creation. But in other directories, the problem doesn't change, still the "Error-write protection". In fact there is something stange when using the script "New Permissions", it seems that this script does something on some disks only. Here is the "command line" from the windows open by the script : /usr/local/sbin/newperms processing /mnt/disk1... chmod -R u-x,go-rwx,go+u,ugo+X /mnt/disk1... chown -R nobody:users /mnt/disk1...sync processing /mnt/disk10... chmod -R u-x,go-rwx,go+u,ugo+X /mnt/disk10... chown -R nobody:users /mnt/disk10... sync processing /mnt/disk11... chmod -R u-x,go-rwx,go+u,ugo+X /mnt/disk11... chown -R nobody:users /mnt/disk11... sync processing /mnt/disk12... chmod -R u-x,go-rwx,go+u,ugo+X /mnt/disk12 But nothing about the disks 2-9 and 13-19..? Does somebody know if this behaviour is correct, if it's possible to run the modification manually or something, and if it's the solution why doesn't the script work correctly inside all the server?

Thanks for replies It seems that those issues are related to the 'mover'. What is this? There is no cache disk in my config, and there is my "go" file : #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & /boot/packages/cache_dirs -w -e "Work" -e "User" /boot/unmenu/uu As you can see, not too much. Any clue? May I use the 'New Permissions" script again with no jeopardy situation?

If it's the script called "New Permissions" in the "Upgrade Utilities", yes. Do you know if it's a good idea to re-launch this script just to be sure? Normally it's a one-time action only....

Hello, I've recently upgrade my unraid from 4.7 to 5.0. It's because I have to add some HDD, and currently the 3TB are cheaper than 2TB... So the NAS with 20 disks upgrade nicely from 4.7 to 5.0, then I've just changed the parity disk from 2TB to 3TB until now. However, I've recently discovered something strange, on some directories inside a share, I cannot delete or rename some files. I've not run a lot of investigation, but I can copy a file into those directories, but I cannot delete this file, or rename it (message = Error : please remove the write protection) On the level just above, no problem. On another directory, no problem at all. f.e. The share is Tower/Video, I can copy a file into directory Video/Films/Web, but there is no way to delete or rename it from windows (no problem with putty and mc). I can also copy the same file into Video/Films or Video/Films/HD-New and in those directories I can delete or rename the file without problem. Of course the shares user access remain constant, it's inside the share itself. Strangely, I can create a directory inside, f.e. Video/Films/Web/Test and there I can copy files, delete and rename, and even delete the directory Test. But it's different for the files. I've never meet this issue when I was on 4.7. Syslog attached (v5.0.5) syslog-2014-03-26.txt