doorunrun

Turl, I mean when clicking the 'Log' icon/button on the main bar. It's all there when using the 'Tools - Syslog' in webUI that you mentioned. That'll do; I just never gotten to it that way. Thanks for pointing that out!

Upgraded without troubles. Congratulations on the update! When checking the log through 'webterminal' I notice that the colored highlighting of some common system functions has been dropped in favor of a slimpier black & white readout. I did not see any mention of this in the release notes or here on the forum. Any plans for this feature returning? Maybe I overlooked something in Settings? Thanks! (P.S. I see my signature is WAAY out of date. I'll fix that soon; just haven't posted in a long time)

Thanks, jonathanm and trurl for the replies! I used MC and got the files moved and finished working through the Wiki to get the drives swapped. I don't plan on converting the other Reiserfs drive I have right away. I don't want to use the 2TB drive I just converted that's sitting in the 'swap' slot and part of the array. I'd like to unassign (remove) it from the array. Would I use the Wiki "Shrink The Array" page's procedure? I will be purchasing a new larger drive for this next conversion of the remaining 2TB Reiserfs drive. I don't see this aspect of the conversion covered in the "File System Conversion" wiki doc, but when you come to the of the process and are doing the last "new config step" could you just not assign the swap slot drive (which is not needed)? I think you have to do a parity check since that 'extra' drive is not part of the array anymore , right? Maybe I overlooked something in the conversion process? I understand things better now that I've gone through it once. Thanks for the help!! --Al

Hello All, I used the mirror procedure outlined in the Wiki page, "File System Conversion," to convert a 2TB Reiserfs (/mnt/disk1) data drive to a 4TB XFS (/mnt/disk4) formatted drive. I'm using unRAID version 6.8.3. ( https://wiki.unraid.net/File_System_Conversion ) The instructions are good and I did my best to follow it to the letter, but it looks like I made a mistake at the command line with the rsync command. As a result, the files on my "swap" (target) drive were pushed down one level so the file structure became: /mnt/disk1/disk1/disk1" after setting up the new configuration with the 4TB drive in the 'disk1' unRAID slot. My error, I believe, was to omit the final slashes ( / ) defining source and target in the rsync command. What I entered was: rsync -avPX /mnt/diskX /mnt/diskY (missing trailing / ) oops!! I reverted back to the original configuration and things appear normal, no errors from "Fix Common Problems." Now, moving forward I'm wondering if I have to do the rsync all over again or if there's a valid way to move the files on what is/was the "swap" (target) drive up one level so they match the /mnt/disk1/user-files. If it's better to do the rsync again should I reformat the "swap" (target drive). In other words, what's the best way, start from scratch? Cheers!

I've been running this version (6.5.3) for a little over a week and I'm happy to report I have not had one of these error messages show up in the log: Tower root: error: /JNAP/: missing csrf_token The error showed up quite frequently on my production system, but not on my testing system. It was reported to be mainly tied to leaving a browser window open through a restart of unRAID. But, this scenario didn't seem to fit in my case (stale login credentials, maybe). I thought I was just going to have to live with it but since the update it's gone. Oh Happy Day! Nothing in my external network--hosts--configuration has changed, so I believe the 'fix' was in the update itself. BTW, I was previously running 6.5.2. Cheers!

I've updated the server I use for OwnCloud to 6.2.0-beta18. Initially things seemed to be normal and I had access to data. After what seemed like a cache drive crash, getting a replacement disk going and reinstalling a OwnCloud Docker, I find that I can no longer connect to my old stored data. It seems as if OwnCloud does not like "/mnt/user/OwnCloud" for the "/array" Container Path setting. At one point in the troubleshooting process I found my "OwnCloud" folder's permissions had changed from "all access" so I chmod-ed to allow all access like the other shares. Well, that didn't help and still OwnCloud is setting up the users database on the cache drive under /mnt/user/appdata/(users-folder). It's been a while since I'd had to troubleshoot issues on unRAID and so my skills are very rusty! Thanks!! =================================== Added Mar 16th.... After a day or two poking around with this, I gave up on this and OwnCloud docker and have moved over to BTSync through the Limetech repo, and even that is pretty poorly documented, help-wise. There's a lot you have to do own your own in my opinion, especially the part about sync-ing folders within unRAID. This seems odd just because it's Limetech's repo......

I upgraded my test server to v6.0-rc3 and set up Dynamix Folder Caching only to find the status page in the GUI says it's stopped (see pix). Is this a reported problem? Any ideas about how to get it fixed? Thanks! EDIT.... I noticed some errors on the console screen after rebooting to the effect the Cache_Dirs.zip file was corrupt. Indeed it was so uninstalling and reinstalling did the trick and now it's running OK.

Not abandoned, will be updating soon. From the above quote by limetech, I'd say the new webGUI is not ready for production yet.

Thanks for the update! This line in the article you quoted may be the understatement of the year! I have found "Classic Shell" http://www.classicshell.net/ an easy way to make Win8 more palitable.

I would just try renaming the Windows username and certainly not have any spaces in it.

A week ago I noticed some odd behavior in my syslog and documented it here: http://lime-technology.com/forum/index.php?topic=29028.msg259284#msg259284 I marked it solved because there seemed to be no clear-cut answer. In this case I was running with the new webGUI and had decided to keep it after upgrading. But today after installing v5.0-i386 AND rebooting the server, I saw in the new webGUI my mover settings had changed again. My mover schedule was now showing as: Monthly--Sunday--01--00--Enabled. I looked through the current syslog, the one that started when I rebooted after the upgrade and the only line in it about "generating mover" was for my regular Daily @ 0330. Hmm....maybe it's something with the webGUI?? I powered down the server and removed the plugins for the webGUI as per Tom's instructions and rebooted to the stock webGUI (the one with the mountain range). Now, looking at the mover settings it shows the right values of 30 3 * * *! And my syslog agrees with this. I may be jumping to the (wrong) conclusion here, but methinks the new webGUI has got an issue with mover settings.

The Lian Li PC-Q25b is a popular and well designed case for NAS building. In a recent thread on these pages it was noted there's not much room for a full sized power supply. see: http://lime-technology.com/forum/index.php?topic=28860.0 Has anyone tried the PE-01 Power Supply Extender? Care to comment?? http://www.newegg.com/Product/Product.aspx?Item=N82E16811995021 (currently out of stock) Thanks for the help!

Hmmm, I wonder why it's doing it on my system? Thanks for checking it out! At least it gave me the opportunity to learn about tr (truncate)!

Thanks Joe L. for writing! The link is the bottom of your original post in this thread, shown as cache_dirs.zip: http://lime-technology.com/forum/index.php?action=dlattach;topic=4500.0;attach=14315 I appreciate the help!

I have been using the Cache_Dirs plugin, but in order to install Tom's new WEB-GUI he requested we delete all plugins from /boot/plugins. That left me without the cache_dirs plugin. What does this have to do with Joe L's cache_dirs script? I thought I'd go ahead and use his script directly and run it manually. So I downloaded it from the link in the OP and after extracting and FTPing it over to my unRAID box I had troubles running it with the error "/bin/bash^M: bad interpreter: No such file or directory." I looked at the file using MCEdit and sure enough there were a bunch of ^M's at the end of each line. This is supposed to mean somewhere along the way a Windows text editor modified the file and added the ^M's as a EOL or CR. I tried a number of ways to correct it but what finally worked was a tip from Joe L. tr -d '\15\32' < cache_dirs > cache_dirs-1 A link to the article: http://lime-technology.com/forum/index.php?topic=911.0;nowap Reply #7 That fixed it and I could run the script. BTW, I run Ubuntu Linux on my workstation and didn't edit the file in any way prior to copying it to my unRAID server. So, is there a problem with the file format of the file in the download link? Thanks!!