coppit

Doh. Yeah, I can fix that. I set up a cron job to run newperms on my cache drive, because transmission does this too. So I didn't notice that these containers have this problem.

Do you literally build and run them in the VM, or have you set DOCKER_OPTS="-H tcp://tower..." so that the containers run in unraid? That's what I was planning to do, since I have one or two containers that I may not share on Docker hub.

I'd like to move my development off of my unraid server. Has anyone worked through setting up TLS on the daemon, so that you connect remotely? Edit: I figured it out, so I'll edit this top post to be a HOWTO. First, I didn't bother setting up security because docker is only exposed on my LAN. If you want security, check out the Docker docs. [*]On your unraid sever, edit /boot/config/docker.cfg, adding two -H options:[br] DOCKER_OPTS="--storage-driver=btrfs -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375" [*]On your remote machine, install the docker client. Then either add the -H tcp://tower:2375 option to your docker command, or put export DOCKER_HOST=tcp://tower:2375 into your ~/.bashrc. When you're done, you can run "docker ps", "docker build" or whatever from your dev machine, with all the action happening on your unraid server. I like this better because I'm on my normal dev machine, with github credentials, my favorite GUI editor, etc.

Does NzbGet write to its /data directory (which you mapped to /mnt/user)? And if so, are the files/directories that it writes to on some non-cache drive? What happens if you configure FileBot's output dir to be /mnt/user? When I get a chance I'll do some experiments, but I don't know how filebot could be somehow telling unraid to spin up the drives, or what I could do to prevent that. The only thing I could imagine doing is filing a bug against unraid.

It seems like the workaround is simple: Specify the output dir within your cache drive, and let mover handle moving it later. Of course FileBot is going to write to the output dir, but from the docker container's perspective it can't control what unraid does with that write, or even that unraid exists. This seems like a general unraid<->docker issue that's not related to filebot. To confirm, you could modify your other containers to also use /mnt/user/... and I bet you'll see the same spin-up behavior. I wonder for example if Docker's volume mapping somehow bypasses or interferes with unraid's cache drive implementation?

I've created a container with a UI. I'm looking for feedback. I've updated the top post with info. It's also available via the "community applications" plugin UI.

Is anyone else having trouble with this container? I sometimes get a client authentication error. Other times it seems to connect, but doesn't show any shares. The only suspicious thing in the logs is this: 22:00:15 ERROR 00 bonjour BonjourImplAvahi.cpp:291 - - - - - - - - Failed to create client: Daemon not running [code] I tried building the container from scratch, but that didn't help. I reverted back to single-user mode, and double-checked my share settings, and everything seems fine. I'm running 6.0rc4 (Docker 1.6.4).

I keep my incomplete files in a separate directory. The change detection only triggers for new directories, files that were open for writing and have been closed, and for files moved into the directory. Opening or writing to a file doesn't trigger it, nor does reading a file. However, some other file in the directory could get written, causing FileBot to run on the whole thing. I don't know if filebot is smart enough to detect when files have opened file handles to them. The safest thing would be to go from incomplete -> complete -> sorted, where complete is FileBot's input, and sorted is its output.

Yeah, I guess it should be filebot-cli or something. It's meant to be no-touch. You could compare the input and output directories, I suppose. I've found UIs in docker containers to be really clunky (web UIs being the exception, of course). If I have some time I'll take a look at a UI, but I wouldn't count on it.

Looking for feedback on a FileBot container: http://lime-technology.com/forum/index.php?topic=40400.0

THIS CONTAINER IS NO LONGER SUPPORTED. PLEASE USE DJOSS' CONTAINER INSTEAD. (Or Sonarr, which is a more comprehensive solution.) FileBot is an automated file renamer and metadata fetcher. Note: I used to have separate UI and non-UI containers. They have now been merged into one container that supports both methods of use. THE UI IS DISABLED BY DEFAULT. To enable it, edit your filebot.conf, setting RUN_UI=true. Then restart the container. You can use this container in automated mode, where you configure FileBot, and then drop files into a "watch dir" that will automatically be converted. Or you can use it in UI mode, where you can either use a remote desktop client or a web browser to use the UI. For more information on usage: https://hub.docker.com/r/coppit/filebot/ For source code: https://github.com/coppit/docker-filebot This container is part of my template repository: https://github.com/coppit/docker-templates Breaking change on June 26, 2016 In order to fix the automated FileBot so that it creates files with nobody:users ownership instead of root:root, I had to change a few things. Unfortunately existing users will need to do a few things to migrate their config files and containers to the new image: Click on your container, then the "Advanced" button in the top right, and add new environment variables: "USER_ID=99", "GROUP_ID=100", and "UMASK=0000" Run "chown nobody:users /path/to/config/*" When you first run it, it will exit and complain in the logs about a filebot.sh version change. You'll need to edit your filebot.sh, bumping the version number to 2 and changing /root to /files

I changed the port to 61738 and it started working again.

I have windows AirVideo running in a VM, and it seems the clients can autodiscover it on the local network. That way I don't have to manually enter the IP address. This docker image doesn't seem to do that. Is that an issue with the Linux server? Or the container? I checked the server's local ports that are open using netstat, comparing against the Bonjour ports listed here, and I don't see any open.

I've integrated most of your changes, and simplified it a bit to not need a separate firstrun.sh script. I've also set up a template repository: https://github.com/coppit/docker-templates

Yeah, I wanted to give them a once-over before putting them in. Done now.

I put it into my template repository. Add this URL to the templates section of the Docker tab: https://github.com/coppit/docker-templates Then create a new container, selecting mumble-server

I'm setting up a template repository for a couple of docker containers I've created. https://github.com/coppit/docker-templates For support for each container, see the appropriate thread: duckdns: Let anyone find your server using a name, even if your IP changes. no-ip: Let anyone find your server using a name, even if your IP changes. mumble: A voice-over-IP solution. I use it for Minecraft chatting for the kids. inotify-command: Run a command when a file changes on the file system. privoxy: Block ads, even on your iDevices.

Since nativedude created a "competing" container instead of contributing to mine, I've just deleted mine. Use his instead. Or use Discord. That's what I'm using now. I've put together a Murmur container. Murmur is the server component of the Mumble voice-over-ip program. https://registry.hub.docker.com/u/coppit/mumble-server/ In the coming days I'll clean it up and put it into a template repository to make it easier for unRAID folks to use it.

No offense taken. For some reason I didn't get notifications for changes on this thread.

Sigh. Why do people fork instead of working together? If you want to maintain your own, which is better than mine, I'll kill my github repo and update the first post to refer to yours. Or I can make you a co-maintainer, or you can send me a pull request.

I'm not sure if the controller has its own BIOS menu. Also, like I said I have 2 other drives (Toshibas) that could go at 3.0 Gb/s, but are running at 6.0 Gb/s.

Well, I tried swapping cables to the controller, and connecting it to my motherboard. Then I pulled the drive and attempted to upgrade its firmware on a Windows machine. It seemed to work, but the BIOS version isn't the latest one. (?) Oh well, if the parity drive's bus speed isn't the limiting factor as you say, I guess I can live with it at 3 Gb/s.

Hi all, I just upgraded my parity drive from 2GB to 3GB. The rest of my drives are 2GB, but the store only had 3GB 7200 SATA3 drives. This is the drive: http://www.newegg.com/Product/Product.aspx?Item=N82E16822148844 Anyway, according to the SMART page in the UI, my parity drive is "sdd", and is not running at the full 6 Gb/s: $ smartctl -a /dev/sdd | grep SATA SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s) The syslog seems to confirm that I'm running slower: $ grep ata.*ST3000DM001 /var/log/syslog Feb 3 19:59:05 storage kernel: ata6.00: ATA-9: ST3000DM001-1ER166, W500ARQN, CC25, max UDMA/133 My controller is the "SuperMicro AOC-SAS2LP-MV8 PCI-Express 2.0 x8 SATA / SAS 8-Port Controller Card". I made sure I'm running the latest firmware for the controller. I checked that I don't have to set any jumpers on the drive to go full speed. I didn't update my hard drive firmware, but I could try that if folks think it would help. I have two other data drives running at 6 Gb/s, so I know the controller can do it. Any ideas? TIA!

I too would be interested in Blue Iris, perhaps interested enough to try building the container myself.

Okay, I think the problem is that your file had DOS line endings. I've updated the code to work around that. Please do: docker pull coppit/duckdns to get the latest version, and try again.