doorunrun

Members
  • Posts

    515
  • Joined

  • Last visited

Converted

  • Gender
    Male
  • Location
    North Florida
  • Personal Text
    Why? Why not?

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

doorunrun's Achievements

Enthusiast

Enthusiast (6/14)

0

Reputation

  1. 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!
  2. 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)
  3. 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
  4. 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!
  5. 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!
  6. Well, when you put it like that, it makes all the sense in the world. Not a 'face palm' moment....more like, DOH! Thanks!
  7. 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
  8. 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!
  9. 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
  10. 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......
  11. Another suggestion, start with a fresh copy of v. 6....that means to make a good backup of your v.5 USB and then format the USB stick and install the v6 files. This would be a clean install. The upgrade guide has good instructions.
  12. How about calling this version "Longboard," to go along with the new graphic? I've updated my production server and everything looks good! Congratulations on this release and thanks for all the hard work from Team Limetech! Bottoms Up, Surf's Up and no Wipe Outs!! BTW, I like having a "Mover" button on the main page!
  13. I updated my rc6 test system to rc6a with good "Docker DNS bug" results. The system's only Docker container is ownCloud and prior to the update had a bad case of the DNS bug. After the initial restart to rc6a and one reboot ownCloud is not reporting Internet connectivity problems. I'll update my production system later today. Now I just got to figure out ownCloud a bit better. Congratulations to Team Limetech on this release!
  14. It's a known issue. From the Defect Reports message group: http://lime-technology.com/forum/index.php?topic=39597.msg380342#msg380342 The quick fix is to set networking to host in the Docker container's config page, save settings and then revert back to bridge mode and save it.
  15. see: http://lime-technology.com/forum/index.php?topic=39597.msg376309#msg376309 It's a known issue and LimeTech says they're working on it.....