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!

Well, when you put it like that, it makes all the sense in the world. Not a 'face palm' moment....more like, DOH! Thanks!

Yes, after a few restarts and testing Browsers it's a bit clearer. I'm attaching the latest diagnostic file reflecting a Safe Boot, Array Not Started and No Dockers mode. I normally use Chrome browser on my Win 10 desktop to manage unRAID and I did have a SONARR extension running on it, but disabled it for troubleshooting purposes. It seems that when Chrome OR Firefox (which I don't normally use) touches unRAID the error is logged. I did have one 'clean' session with between unRAID and Firefox using a private browsing window. I'll try it again to make sure and go from there. Thanks again!! tower-diagnostics-20180207-1357.zip

Squid, thanks for the link. I had looked over that message in my earlier searches, and since I'm running in 'Safe Mode' and getting the errors, it might point to the two Dockers (Sonarr & NZBGet) from linuxserver.io. I guess the next step is to not start/disable those Dockers and reboot and see where pops up, right? I did follow the link's link and read about "Cross Site Request Forgery." Thanks again!

Hello All, I've been away from this forum for awhile, but been updating my system with each new release. After updating to 6.4.0 I started noticing this error, "Tower root: error: /JNAP/: missing csrf_token" in the log. Along this same time I had issues with SAB and Sickbeard dockers, so I worked on moving over to Sonarr and NZBGet. Now that that migration is over the system is working great. However this missing csrf_token message pops up in the log on a regular basis. I've searched this forum for answers and found a couple suggestions. The 'close tab' on browser is one, but this error keeps showing up after multiple reboots of unRAID and closing/rebooting browser/computer. ****** Oops, hit enter by mistake ************* The attached diagnostic log was taken while running in safe mode. Thanks for the help! --Al tower-diagnostics-20180207-1128.zip

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.