TXFI

Sorry for the noise, I removed my posts until I have definite proof that my problems have something to do with unRAID. Thank you for your help, dikkiedirk - I think you're probably on the right track. All motherboard features have been disabled but I think my issues are caused by the old P5Q Deluxe not being able to handle my Dell H310 or the USB 3.1 card. Sounds like it's time to invest into a new motherboard.

I've been running my Truecrypt unRAID for 10 months now and it is 100% stable and reliable. I have five 1.5 TB containers formatted with RaiserFS, which I mount with a shell script at boot (truecrypt /mnt/disk1/data-01 /data/data-01). I would imagine I could use an NTFS container, too, if I loaded NTFS-3G but since I have no need for it, I haven't tried it. All the necessary packages are installed from /boot/custom prior to mounting by the same script, including the TrueCrypt binary (which I downloaded from repository.slacky.eu along with all the other packages). To share the encrypted data from mount points I have my own smb.conf and smb.shares, which are copied and enabled (smbcontrol smbd reload-config) at boot as well. Since I never stop the array, Bubba's concern about smb.shares getting overwritten is not a problem for me. The key to get all this working was a custom kernel and modified source files, which I had to build using a full Slackware distro. It's been a while now so I don't exactly remember what I had to change but kapperz's error message about device-mapper missing from the kernel sounds very familiar. To smino's point, the reason is that I consider my network to be fairly secure. If, however, someone would e.g. steal my server he wouldn't be able to read the data in the encrypted containers (without torturing the passwords out of me or cracking the encryption, in either case I'm likely to be dead. Or maybe use a cold boot attack or a (remote) keylogger).

bubbaQ, you're still compiling Tom's unRAID SW into bubbaRAID, right? It's not like you can claim any ownership of his work or the rest of the open source you are packaging so why not use unRAId to make it clear to people that your baseline IS unRAID? Without Tom's work bubbaRAID would be just a slim Slackware distro that does nothing special... If asked, Tom might even agree to the naming convention, as long as his IPR is protected in terms of unRAID. Again, I'm not here to start a flame war, just saying that "bubbaRAID" could be misleading some newbies to think it's something better than from where Tom gets his bread and butter. I'm also very well aware of your outstanding contributions towards the unRAID community so far and thus will leave it to your best discretion what to do about this topic, if anything. Thank you!

I don't mean to be disrespectful - bubbaRAID seems like a great product - but since it wouldn't have parity/redundancy without unRAID, wouldn't a more appropriate name for it be unRAID-bubba or unRAID-bubbaQ? There could even be a naming convention for user-created unRAID mods where: - "unRAID-" is a mandatory prefix - name of the mod comes after the dash - no version numbering in the name and when announcing a release of a new mod, you would also add version numbering like: "unRAID-bubbaQ-4.4.2-1.0 released" where 4.4.2 is the unRAID version it is based on and 1.0 is the version of the mod. Just a thought...

boof: I have a draft of my install notes, which I need to clean up so that someone else could understand it, too. Hopefully I can get to that after I get vmware and jungledisk (waiting for 2.50 final) running OK. Now that the holidays are over I have far less time to dedicate to this, though. In order to get it to work, I had to compile a custom kernel with modified makefiles to enable unRAID and dm-mod at the same time. Then I just created the container files into /mnt/disk?/, thus enabling unRAID to manage parity as it's just files, even though they are 1.34 TB each or so. I wanted to leave a little bit of space on each disk - they have 800 MB free space/each. If I wanted to fill the disks completely, it would be just a matter of increasing the size when creating the TC containers. I install all the necessary libraries etc. and mount the drives after unRAID has finished booting with a custom shell script. If I wanted I could just call it with the "go" script/embed it into the "go" script and have it do everything at boot (or just install all the stuff into the bootimage). However, I never enter my TrueCrypt passwords using anything but a wired keyboard at local console so manually running the mount script was a design decision for me, not a missing feature. ---- Bubbaq: Yeah, symlinking turned out to be a bad idea. Instead I just mount the containers to another root folder, have turned off all unRAID shares and just share the stuff as I please via smb.shares. Seems to be working well and fast (initial test results were about 50MB/s from encrypted unRAID to my Vista box).

well this certainly turned out to be easier than I thought - just by symlinking the directories inside the encrypted containers to /mnt/disk*/ made the user shares work just fine. I disabled disk shares so that the container files aren't accessible from the network and since symlinking worked so well I don't have to create the shares to my files manually. All in all, I now have a fault tolerant, encrypted storage server that consolidates views of my data from all the encrypted+mounted containers into user shares. In case someone ends up stealing my server, all they'll find are 4 x 1.45 TB files full of gibberish ;-) No wonder you guys like unRAID so much!

I'm an unRAID newbie and have never used Slackware so this is all kind of new to me and am looking for some help. Anyway, I just finished installing the HW and SW (v4.4) for my new unRAID server today and as I was kind of missing encryption I decided to see what could be done about it. Apparently Truecrypt seems to work well with unRAID. After a couple of hours of fiddling with the package manager, kernel config etc. I'm currently able to do the following within unRAID console using native tools: - create encrypted volumes (create a TC container to e.g. /mnt/disk1/crypt-01) - mount encrypted volumes (mount to e.g. /crypt/crypt-01) - share encrypted+mounted volumes via e.g. CIFS (e.g. \\my-unRAID\crypt-01) - reading and writing from/to encrypted+mounted volumes via the CIFS share from another host (tested only Linux and Windows XP so far) - unmount volumes I haven't started to look into mapping encrypted+mounted volumes to user shares. I don't have too much time to dedicate to this project since my initial design goals are working (fault tolerance and encryption) but it would be nice to get the user shares working. It would be great if you could give me some pointers on how to get started, I'm kind of feeling lazy and don't feel like figuring it out myself (at least not this week). The other thing I might do is use ntfs3g instead of reiserfs to format the container. That should enable me to mount the container over the network using Windows Truecrypt without the not-so-conveinent reiserfs drivers, in case I would ever want to mount the container remotely (unlikely). I don't see this as a big issue as I can just mount the container within unRAID and share it to Windows - if in an emergency I'd need to connect a unRAID drive to Windows I'd need the reiserfs driver anyway to read the file system hosting the container. Any thoughts on this? Btw, here's a link to where I show off my new server: http://lime-technology.com/forum/index.php?topic=2031.msg24317#msg24317 Tom - thanks for a great product. Everyone else - thanks for a great forum.

Here's mine. Specs: MSI P43 Neo3-F, iE5200, 2 x 1GB and 5 x 1.5TB Mods: I added a handle to ease moving it around, removed the front USB etc. ports and relocated the power button to the back to avoid accidental shutdown. Reset button is not even connected. Everything else is pretty much stock.

(removed)