Traxxus

That works. Restarted multiple times, changing different values everytime, all persisted. Thanks. And thanks for the docker, torrents was one of the last things I needed to move to the server, but hadn't because I didn't want to have to bother with setting up the networking side of things to get it to use the VPN. This makes it easy.

My changes do take effect on the downloads, but after a restart the configuration changes are back at the default settings (though looking in the options tab of individual downloads, the torrents themselves do still remember where they are and where they are to be moved). Looking at the 2 core.conf files, after changing the settings and saving them, they do not appear to have been saved in the configuration files, it still has the default location of /home/nobody.

No joy, still not saving my configuration changes. supervisord log http://pastebin.com/cNkMx7qV

Good catch, but no, it's apps.

I can't get deluge to save my settings, whenever I try to change the download locations it only persists until I restart it. It does save my password changes though. Log file says config:388 Unable to load config file: /config/core.conf [iNFO ] 17:25:17 configmanager:70 Setting config directory to: /config [iNFO ] 17:25:17 daemon:124 Deluge daemon 1.3.12 [iNFO ] 17:25:17 configmanager:70 Setting config directory to: /config [iNFO ] 17:25:17 core:80 Starting libtorrent 1.0.6.0 session.. [WARNING ] 17:25:17 core:187 Failed to load lt state: [Errno 2] No such file or directory: '/config/session.state' [ERROR ] 17:25:17 config:387 Expecting property name: line 98 column 1 (char 2432) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/deluge/config.py", line 385, in load self.__config.update(json.loads(data[start:end])) File "/usr/lib/python2.7/json/__init__.py", line 338, in loads return _default_decoder.decode(s) File "/usr/lib/python2.7/json/decoder.py", line 366, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "/usr/lib/python2.7/json/decoder.py", line 382, in raw_decode obj, end = self.scan_once(s, idx) ValueError: Expecting property name: line 98 column 1 (char 2432) [WARNING ] 17:25:17 config:388 Unable to load config file: /config/core.conf [iNFO ] 17:25:17 rpcserver:367 Starting DelugeRPC server localhost:58846 [ERROR ] 17:25:17 component:118 [Failure instance: Traceback: <type 'exceptions.RuntimeError'>: Address family not supported by protocol /usr/lib/python2.7/site-packages/deluge/main.py:230:start_daemon /usr/lib/python2.7/site-packages/deluge/core/daemon.py:161:__init__ /usr/lib/python2.7/site-packages/deluge/component.py:296:start /usr/lib/python2.7/site-packages/deluge/component.py:124:_component_start --- <exception caught here> --- /usr/lib/python2.7/site-packages/twisted/internet/defer.py:150:maybeDeferred /usr/lib/python2.7/site-packages/deluge/core/preferencesmanager.py:162:start /usr/lib/python2.7/site-packages/deluge/config.py:312:register_set_function /usr/lib/python2.7/site-packages/deluge/core/preferencesmanager.py:258:_on_set_listen_interface /usr/lib/python2.7/site-packages/deluge/core/preferencesmanager.py:276:_on_set_random_port ] [ERROR ] 17:25:17 component:118 [Failure instance: Traceback: <type 'exceptions.RuntimeError'>: Address family not supported by protocol /usr/lib/python2.7/site-packages/deluge/main.py:230:start_daemon /usr/lib/python2.7/site-packages/deluge/core/daemon.py:169:__init__ /usr/lib/python2.7/site-packages/deluge/component.py:296:start /usr/lib/python2.7/site-packages/deluge/component.py:124:_component_start --- <exception caught here> --- /usr/lib/python2.7/site-packages/twisted/internet/defer.py:150:maybeDeferred /usr/lib/python2.7/site-packages/deluge/core/preferencesmanager.py:162:start /usr/lib/python2.7/site-packages/deluge/config.py:312:register_set_function /usr/lib/python2.7/site-packages/deluge/core/preferencesmanager.py:258:_on_set_listen_interface /usr/lib/python2.7/site-packages/deluge/core/preferencesmanager.py:276:_on_set_random_port ] [iNFO ] 17:25:17 torrentmanager:642 Successfully loaded state file: /config/state/torrents.state [WARNING ] 17:25:17 torrentmanager:653 Unable to update state file to a compatible version: list index out of range [WARNING ] 17:25:17 torrentmanager:762 Unable to load fastresume file: [Errno 2] No such file or directory: '/config/state/torrents.fastresume' [WARNING ] 17:25:17 torrentmanager:762 Unable to load fastresume file: [Errno 2] No such file or directory: '/config/state/torrents.fastresume.bak' [iNFO ] 17:25:18 rpcserver:204 Deluge Client connection made from: 127.0.0.1:56911 [iNFO ] 17:25:18 rpcserver:204 Deluge Client connection made from: 127.0.0.1:56912 [iNFO ] 17:25:18 rpcserver:224 Deluge client disconnected: Connection to the other side was lost in a non-clean fashion: Connection lost. [iNFO ] 17:25:18 rpcserver:224 Deluge client disconnected: Connection to the other side was lost in a non-clean fashion: Connection lost. [iNFO ] 17:25:18 rpcserver:204 Deluge Client connection made from: 127.0.0.1:56913 [iNFO ] 17:25:18 rpcserver:224 Deluge client disconnected: Connection to the other side was lost in a non-clean fashion: Connection lost. [iNFO ] 17:25:19 rpcserver:204 Deluge Client connection made from: 127.0.0.1:56915 [iNFO ] 17:25:19 rpcserver:224 Deluge client disconnected: Connection to the other side was lost in a non-clean fashion: Connection lost. [iNFO ] 17:25:19 rpcserver:204 Deluge Client connection made from: 127.0.0.1:56916 [iNFO ] 17:25:19 rpcserver:224 Deluge client disconnected: Connection to the other side was lost in a non-clean fashion: Connection lost. [iNFO ] 17:25:19 rpcserver:204 Deluge Client connection made from: 127.0.0.1:56917 [iNFO ] 17:25:19 rpcserver:224 Deluge client disconnected: Connection to the other side was lost in a non-clean fashion: Connection lost. [iNFO ] 17:25:19 rpcserver:204 Deluge Client connection made from: 127.0.0.1:56918 [iNFO ] 17:25:20 rpcserver:224 Deluge client disconnected: Connection to the other side was lost in a non-clean fashion: Connection lost. [iNFO ] 17:25:20 rpcserver:204 Deluge Client connection made from: 127.0.0.1:56919 [iNFO ] 17:25:20 rpcserver:224 Deluge client disconnected: Connection to the other side was lost in a non-clean fashion: Connection lost. [iNFO ] 17:25:20 rpcserver:204 Deluge Client connection made from: 127.0.0.1:56920 [iNFO ] 17:28:37 torrentmanager:723 Saving the state at: /config/state/torrents.state /config is mapped to /mnt/user/apps/appdata/delugevpn Apps is the cache only share that has all my docker stuff and images. Any thoughts? I've tried reinstalling, no dice.

I had a similar issue regarding spindown>parity errors, mine went away though. I don't know exactly what resolved it. I consolidated lots of smaller drives onto a few larger drives and went to all motherboard sata connections (SASLP currently not in use anymore) and redid the cabling.

Powerdown Dyn system temp Dyn system stats Dyn system info Dyn auto fan control Dyn cache directories

Awesome, it worked, thanks!

I can access the webgui, ping the server, going to start and \\tower or \\ip\folder will also bring it up, it just doesn't show up in my Network Places for some reason. It used to, but it stopped a while back. It's not really a huge deal, but it would be nice for it to show up there properly for ease of use. The IP address for it is reserved through the router via mac address. I've tried Yes and No to Local Master. 2 Windows 7 machines exhibit the same behavior. Since everything else works I get the feeling it's something stupid I've overlooked but I don't know.

As mentioned by others, my cache drive now displays as unformatted. Unlike the previous posts, mine was btrfs formatted. Manually mounting the device results in a "bad superblock" message. I'm a long time unRAID user and am happy to financially contribute. That being said, I have a hard time justifying an upgrade from a free/trial license when my entire cache drive has just been compromised by a system upgrade. To be fair, it is a beta.

Upgrade went well. I like the addition of the Dockers to the Dashboard, and the volume mappings table in the docker sections.

Wow, I just replaced the fans in the SS-500 with Noctua RF-8, what a huge difference in noise, the thing sounded like a jet engine with 2 or 3 (third is disconnected right now, I decided to remove some of the older drives). I turned it on and had to check if they were even spinning. Much more reasonable now, even though it's in an unused room you could still hear it outside the door. Also added a couple 120mm to as exhaust on the top of the case to help alleviate some of the load on the enclosure fans. Since I had to mess with cables I'm running a parity check, ambient temp is around 70F, drive temps holding around 30-34C. One is 36C, that's probably the cage with 3 empty slots, so all the air is going through the empty bays instead of between the drives, need to block those off. Changing the fans was much easier than I thought it would be. Pop the back, unhook old fan, unscrew it, push it out in a star pattern to get them off the pins, replace. I'm happy.

Most of the newer intel stuff is about as power efficient as you can get. The system in my sig is a beast, but only idles at 46 watts w/ cache drive (WD 1TB) spun up.

I've noticed this too, some notifications don't get sent out until I open the webgui.

You shouldn't do this. The outside of those antistatic bags tend to be conductive, that's how they protect components inside the bag. Putting the components on top of the bag serves no purpose, it will not protect anything, and could damage something. They are good for shipping or storing, not as a work surface. Much better to just put it on the cardboard box it came in, or on wood.

NICE! First I've seen with 120MM fans. About time! Absolutely !! Really nice to see the large fans on these -- not only that, but they're VERY reasonably priced. It'll be very interesting to see what drive temps you get with these cages. Agreed, looks simple to change the fan as well. Nice.

First, use screen, to install http://lime-technology.com/forum/index.php?topic=37472 Use MC in a telnet session (using screen so you can disconnect/shutdown/whatever) to move files, not windows explorer. Using explorer will cause you to have to do 2 moves, one to your workstation, then another back to the unraid server. MC will move disk to disk and leave the network out of it. I think a full 2 TB drive took ~12 hours, so still not fast. You were on the right track, but starting with your smallest drives was where you went wrong. Should've started with the largest. Doing the smallest first means you will have to move subsequent files to multiple drives. Doing the largest first would have ensured you always have room the for the next drive. I would do your next largest now, however you can, and then continue going from largest to smallest. http://lime-technology.com/forum/index.php?topic=37490.0

That's unreadable.

Do one thing at a time. This won't be a quick process, and if something goes wrong you want to be able to pin down when/where it happened. I wouldn't replace the disks yet, since the rebuild is going to rebuild the disk bit by bit, which includes the filesystem, so do that last. Easiest way, assuming you have the ability/space to, would be to add the new drives you have as additional drives, format to XFS, and start with those. Copy data from non-xfs drives to those new xfs drives, then format those now empty drives. Rinse and repeat. Your total array size is 20 TB, and the new drives are 10, so that would cut down on the amount of musical chairs you have to do. Then after you are done, you can shrink your array and remove those 3 drives you wanted to remove. If you don't have room for the new drives, then same thing, just with your existing drives. There's a sticky about this. http://lime-technology.com/forum/index.php?topic=37490.0

Read this quoted post first. The appdata folder is for files the docker needs to write and store, such as config files, settings files, etc. Dockers are self contained and do not have access to your other files, except for what you specifically allow. Here is an example setup for couchpotato. You can see that the appdata folder is mapped to simply /config. When setting CP up itself through the webgui, all you need to put in is /config, /downloads, /movies etc. It's not hard once you start thinking about them in the context of being self contained dockers (or essentially a VM), and not just plugins. Note in the image, apps is my cache only share, appdata is within that, You need to change your path to whatever yours is.

http://lime-technology.com/forum/index.php?topic=36295.0;topicseen I believe it to be related to the issue in the above thread. Nobody has quite pinned down the cause, and different solutions seem to work for some and not others. Disabling spindown, xen boot, not mixing ezpansion and motherboard ports, having all drives the same filesystem, etc. Rebuild is finished, so I'm going to convert the last drive to xfs, issue occurred when moving a large amount of files from a RFS drive to an XFS drive, though that shouldn't cause problems. I'll try removing 2 of the 2TB drives and running off the saslp or motherboard only next.

Well, I did memtest overnight just to rule that out, no errors after ~16 hours. Since the smart report was fine, I did xfs_repair with no arguments to fix the filesystem. Some files were put in the lost and found, but they are small files and it referenced the .actor folder so probably just metadata/images, everything else looks okay and haven't found any corrupted files, but it's over 3.5 TB worth of tv episodes so who knows. I am currently rebuilding to the same drive.

I left a file transfer going yesterday, copying 3+TB from disk2 to disk3, came in this morning to an unresponsive disk 3 and 4, and unraid complaining about they failed smart something or other. Stopped the array, and both drives disappeared from the device list. I reseated both, performed a clean reboot (log included is from before reboot), and both drives do show up now, however disk 3 is disabled (4 appears to be fine), and appears to have some sort of file corruption going on from the logs. I started in maintenance mode and ran the check filesystem and got this. xfs_repair /dev/md3 -n 2>&1 Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 bad directory block magic # 0x5b444042 in block 0 for directory inode 17074 corrupt block 0 in directory inode 17074 would junk block no . entry for directory 17074 no .. entry for directory 17074 problem with directory contents in inode 17074 would have cleared inode 17074 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 1 bad directory block magic # 0x5b444042 in block 0 for directory inode 17074 corrupt block 0 in directory inode 17074 would junk block no . entry for directory 17074 no .. entry for directory 17074 problem with directory contents in inode 17074 would have cleared inode 17074 entry ".actors" at block 0 offset 120 in directory inode 21523196102 references free inode 17074 would clear inode number in entry at offset 120... No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... entry ".actors" in directory inode 21523196102 points to free inode 17074, would junk entry bad hash table for directory inode 21523196102 (no data entry): would rebuild - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 17075, would move to lost+found disconnected inode 17076, would move to lost+found disconnected inode 17077, would move to lost+found disconnected inode 17078, would move to lost+found disconnected inode 17079, would move to lost+found disconnected inode 17080, would move to lost+found disconnected inode 17081, would move to lost+found disconnected inode 17082, would move to lost+found disconnected inode 17083, would move to lost+found disconnected inode 17084, would move to lost+found disconnected inode 17085, would move to lost+found disconnected inode 17086, would move to lost+found Phase 7 - verify link counts... would have reset inode 21523196102 nlinks from 8 to 7 No modify flag set, skipping filesystem flush and exiting. For disk4 xfs_repair /dev/md4 -n 2>&1 Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 5 - agno = 4 - agno = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. What now? Is my data in danger? syslog-20150107-082426.zip disk3.txt disk4.txt

This would be a great idea. I like unmenu and used it a lot, but I'm trying to keep my install as simple as possible this time around.

Not saying this is an appropriate way of dealing with it, but I guarantee it will solve the immediate issue. Perhaps set up a "throw away" google account to auto forward unraid messages, and reduce the security settings on it to allow unraid to use it. This is what I did, surely you guys aren't using your real email for things like this?