Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

[ARCHIVE] binhex docker repository

Featured Replies

/media is just a sample really. You can name new ones.

 

 

Add the following:

 

/tv                    /mnt/user/Videos/TV/

/movies            /mnt/user/Videos/Movies/

/standup          /mnt/user/Videos/Stand-up Comedy/

/music              /mnt/user/Music/

 

Then within Plex you can point it to /tv  /movies  /standup  /music  to find your media.

 

Ok I did this and unRAID automatically created user shares for tv, movies, standup, and music.  Is this normal?  The shares kind of are redundant no since I already have a Videos share that has TV, Movies, and Standup within it.

  • Replies 1.6k
  • Views 305.8k
  • Created
  • Last Reply

In windows you need to get to the Credentials Manager (usually under Control Panel). Fine the one(s) that reference your unraid server and delete them.

 

Then navigate to \\tower\myusershare again. If it asks for a username / password type nobody and hit enter. Might have to type a PW as well, just type nobody again.

 

I tried it and it says access is denied.  user name=nobody  password=nobody.

 

Is the share setup as private, secure, or public?

 

I switched the cache security to public and managed to delete all those torrent files.  From now on I'll just have deluge delete them.  Thanks for your help mr hexen!

In windows you need to get to the Credentials Manager (usually under Control Panel). Fine the one(s) that reference your unraid server and delete them.

 

Then navigate to \\tower\myusershare again. If it asks for a username / password type nobody and hit enter. Might have to type a PW as well, just type nobody again.

 

I tried it and it says access is denied.  user name=nobody  password=nobody.

 

Is the share setup as private, secure, or public?

 

I switched the cache security to public and managed to delete all those torrent files.  From now on I'll just have deluge delete them.  Thanks for your help mr hexen!

 

Unless you have reason to within your home just leave all shares as public to keep things simple.

/media is just a sample really. You can name new ones.

 

 

Add the following:

 

/tv                    /mnt/user/Videos/TV/

/movies            /mnt/user/Videos/Movies/

/standup          /mnt/user/Videos/Stand-up Comedy/

/music              /mnt/user/Music/

 

Then within Plex you can point it to /tv  /movies  /standup  /music  to find your media.

 

Ok I did this and unRAID automatically created user shares for tv, movies, standup, and music.  Is this normal?  The shares kind of are redundant no since I already have a Videos share that has TV, Movies, and Standup within it.

 

Please post a screen shot of your the docker setup for this one. I'm lost to what you've done here..

Hello all, can anyone help?  I can't access my sickbeard docker app.  I remapped the container port from 8081, to 8082 (Host port). 

 

I have a portion of my logs pasted below:

 

2015-06-26 03:33:20,713 DEBG 'sickbeard' stderr output:

03:33:20 INFO::SEARCHQUEUE-RSS-SEARCH :: Changing all old missing episodes (UNAIRED) to status WANTED

 

2015-06-26 03:33:20,717 DEBG 'sickbeard' stderr output:

03:33:20 INFO::SEARCHQUEUE-RSS-SEARCH :: Beginning search for new episodes on RSS

 

2015-06-26 03:33:20,718 DEBG 'sickbeard' stderr output:

03:33:20 INFO::SEARCHQUEUE-RSS-SEARCH :: Searching all providers for any needed episodes

 

2015-06-26 03:33:22,528 DEBG 'sickbeard' stderr output:

03:33:22 INFO::SEARCHQUEUE-RSS-SEARCH :: Clearing newztown cache and updating with new information

 

2015-06-26 03:33:31,561 DEBG 'sickbeard' stderr output:

03:33:31 INFO::SEARCHQUEUE-RSS-SEARCH :: Clearing Womble's Index cache and updating with new information

 

2015-06-26 03:33:50,917 DEBG 'sickbeard' stderr output:

03:33:50 INFO::SEARCHQUEUE-RSS-SEARCH :: Clearing Usenet-Crawler cache and updating with new information

 

2015-06-26 03:34:01,192 DEBG 'sickbeard' stderr output:

03:34:01 INFO::SEARCHQUEUE-RSS-SEARCH :: Clearing Sick Beard Index cache and updating with new information

 

2015-06-26 03:34:13,108 DEBG 'sickbeard' stderr output:

03:34:13 INFO::SEARCHQUEUE-RSS-SEARCH :: Clearing nzbfinder.ws cache and updating with new information

 

2015-06-26 03:34:20,918 DEBG 'sickbeard' stderr output:

03:34:20 INFO::SEARCHQUEUE-RSS-SEARCH :: No needed episodes found on the RSS feeds

 

With the logs above, it seems my sickbeard is running.  I've tried both https and http://192.168.1.103:8082, but SB cannot be accessed.  I've deleted my image, and reinstalled the docker (without deleting the sb folder yet- config files still inside) but still won't be accessed.

 

How do I access?  How do I even validate it's service status? 

Screen_Shot_2015-06-25_at_19_40_53.png.f63c7ab6d3cf6ee8dcb86b62f528eb45.png

  • Author

Hello all, can anyone help?  I can't access my sickbeard docker app.  I remapped the container port from 8081, to 8082 (Host port). 

 

I have a portion of my logs pasted below:

 

2015-06-26 03:33:20,713 DEBG 'sickbeard' stderr output:

03:33:20 INFO::SEARCHQUEUE-RSS-SEARCH :: Changing all old missing episodes (UNAIRED) to status WANTED

 

2015-06-26 03:33:20,717 DEBG 'sickbeard' stderr output:

03:33:20 INFO::SEARCHQUEUE-RSS-SEARCH :: Beginning search for new episodes on RSS

 

2015-06-26 03:33:20,718 DEBG 'sickbeard' stderr output:

03:33:20 INFO::SEARCHQUEUE-RSS-SEARCH :: Searching all providers for any needed episodes

 

2015-06-26 03:33:22,528 DEBG 'sickbeard' stderr output:

03:33:22 INFO::SEARCHQUEUE-RSS-SEARCH :: Clearing newztown cache and updating with new information

 

2015-06-26 03:33:31,561 DEBG 'sickbeard' stderr output:

03:33:31 INFO::SEARCHQUEUE-RSS-SEARCH :: Clearing Womble's Index cache and updating with new information

 

2015-06-26 03:33:50,917 DEBG 'sickbeard' stderr output:

03:33:50 INFO::SEARCHQUEUE-RSS-SEARCH :: Clearing Usenet-Crawler cache and updating with new information

 

2015-06-26 03:34:01,192 DEBG 'sickbeard' stderr output:

03:34:01 INFO::SEARCHQUEUE-RSS-SEARCH :: Clearing Sick Beard Index cache and updating with new information

 

2015-06-26 03:34:13,108 DEBG 'sickbeard' stderr output:

03:34:13 INFO::SEARCHQUEUE-RSS-SEARCH :: Clearing nzbfinder.ws cache and updating with new information

 

2015-06-26 03:34:20,918 DEBG 'sickbeard' stderr output:

03:34:20 INFO::SEARCHQUEUE-RSS-SEARCH :: No needed episodes found on the RSS feeds

 

With the logs above, it seems my sickbeard is running.  I've tried both https and http://192.168.1.103:8082, but SB cannot be accessed.  I've deleted my image, and reinstalled the docker (without deleting the sb folder yet- config files still inside) but still won't be accessed.

 

How do I access?  How do I even validate it's service status?

 

hmm odd, that screenshot looks fine to me, and infact i have just reproduced your setup here, container port 8081, host port 8082, and i can connect to http://<unraidip>:8082/home/ and i can see the SB interface.

 

can you try appending /home/ to the url just incase its not redirecting you, if thats a no go then stop the docker, and delete all files/folders in your host path for SB /config and start again.

Could be a crazy thing but I have found several of my dockers simply won't load inside Google chrome even with all addons disabled. For some I have to use Firefox. Maybe try another browser?

binhex, deleting /mnt/cache/.sickbeard worked.  Thanks. 

 

Dimtar, other docker apps working fine with Opera browser.  Furthermore, I was able to access it before.

 

Thanks

binhex, deleting /mnt/cache/.sickbeard worked.  Thanks. 

 

Dimtar, other docker apps working fine with Opera browser.  Furthermore, I was able to access it before.

 

Thanks

 

I think this was your problem

2015-06-25 08:14:55,846 DEBG 'sickbeard' stderr output:
08:14:55 INFO::MAIN :: Starting Sick Beard on http://0.0.0.0:8082/

  • Author

binhex, deleting /mnt/cache/.sickbeard worked.  Thanks. 

 

Dimtar, other docker apps working fine with Opera browser.  Furthermore, I was able to access it before.

 

Thanks

 

I think this was your problem

2015-06-25 08:14:55,846 DEBG 'sickbeard' stderr output:
08:14:55 INFO::MAIN :: Starting Sick Beard on http://0.0.0.0:8082/

 

ahh good catch mr-hexen!, yes the port has been changed for the container side, thus when you did container port 8081 to host port 8082 it didnt work, as the container work was incorrectly set as 8082.

 

jang430 - keep in mind the container port should NOT be changed, its only the host port that can be modified.

binhex, deleting /mnt/cache/.sickbeard worked.  Thanks. 

 

Dimtar, other docker apps working fine with Opera browser.  Furthermore, I was able to access it before.

 

Thanks

 

I think this was your problem

2015-06-25 08:14:55,846 DEBG 'sickbeard' stderr output:
08:14:55 INFO::MAIN :: Starting Sick Beard on http://0.0.0.0:8082/

 

ahh good catch mr-hexen!, yes the port has been changed for the container side, thus when you did container port 8081 to host port 8082 it didnt work, as the container work was incorrectly set as 8082.

 

jang430 - keep in mind the container port should NOT be changed, its only the host port that can be modified.

 

I'm guessing here that a previous sickbeard install in ".sickbeard" was messing the settings up, possibly an old .conf file.

 

Is the IP of 0.0.0.0 even proper? Should that be 127.0.0.1?

  • Author

binhex, deleting /mnt/cache/.sickbeard worked.  Thanks. 

 

Dimtar, other docker apps working fine with Opera browser.  Furthermore, I was able to access it before.

 

Thanks

 

I think this was your problem

2015-06-25 08:14:55,846 DEBG 'sickbeard' stderr output:
08:14:55 INFO::MAIN :: Starting Sick Beard on http://0.0.0.0:8082/

 

ahh good catch mr-hexen!, yes the port has been changed for the container side, thus when you did container port 8081 to host port 8082 it didnt work, as the container work was incorrectly set as 8082.

 

jang430 - keep in mind the container port should NOT be changed, its only the host port that can be modified.

 

I'm guessing here that a previous sickbeard install in ".sickbeard" was messing the settings up, possibly an old .conf file.

 

Is the IP of 0.0.0.0 even proper? Should that be 127.0.0.1?

 

0.0.0.0 is correct (listen on all ip's), if it only was to talk on local loopback (127.0.0.1) then i dont believe you would be able to connect, might be wrong there though.

binhex, deleting /mnt/cache/.sickbeard worked.  Thanks. 

 

Dimtar, other docker apps working fine with Opera browser.  Furthermore, I was able to access it before.

 

Thanks

 

I think this was your problem

2015-06-25 08:14:55,846 DEBG 'sickbeard' stderr output:
08:14:55 INFO::MAIN :: Starting Sick Beard on http://0.0.0.0:8082/

 

ahh good catch mr-hexen!, yes the port has been changed for the container side, thus when you did container port 8081 to host port 8082 it didnt work, as the container work was incorrectly set as 8082.

 

jang430 - keep in mind the container port should NOT be changed, its only the host port that can be modified.

 

Should docker make these ports "locked" to prevent this in the future?  Or at least pop up a warning explaining this before allowing them to be modified/deleted.  Just an idea :)

  • Author

binhex, deleting /mnt/cache/.sickbeard worked.  Thanks. 

 

Dimtar, other docker apps working fine with Opera browser.  Furthermore, I was able to access it before.

 

Thanks

 

I think this was your problem

2015-06-25 08:14:55,846 DEBG 'sickbeard' stderr output:
08:14:55 INFO::MAIN :: Starting Sick Beard on http://0.0.0.0:8082/

 

ahh good catch mr-hexen!, yes the port has been changed for the container side, thus when you did container port 8081 to host port 8082 it didnt work, as the container work was incorrectly set as 8082.

 

jang430 - keep in mind the container port should NOT be changed, its only the host port that can be modified.

 

Should docker make these ports "locked" to prevent this in the future?  Or at least pop up a warning explaining this before allowing them to be modified/deleted.  Just an idea :)

 

nice idea!, i think they probably should be locked, i cant think of a valid reason for them to be changed by the end user, as long as the end user could delete the port if they wanted. @jonp what do you reckon, worthy of enhancement request?

Hmm, sounds more like something we need to better manage with XML templates, right?  E.g. when a containers docker file is changed to reflect new "expose" ports, the template for that container should be updated as well?  Let me know if I'm missing something here.

  • Author

Hmm, sounds more like something we need to better manage with XML templates, right?  E.g. when a containers docker file is changed to reflect new "expose" ports, the template for that container should be updated as well?  Let me know if I'm missing something here.

 

yes def that as well!!, but i think the suggestion justinchase was making was to prevent the user from changing the container port number as defined by the docker template when they are editing, this should then prevent a user from incorrectly modifying the container port and then scratching their head wondering why they cant connect to it.

Ok, yes definitely. That does happen when you are adding a new container with ports defined in the XML template. It appears that when you edit an existing container though, we let folks edit the container port. Probably shouldn't do that. Will discuss with Eric as this may just be a bug.

  • Author

Ok, yes definitely. That does happen when you are adding a new container with ports defined in the XML template. It appears that when you edit an existing container though, we let folks edit the container port. Probably shouldn't do that. Will discuss with Eric as this may just be a bug.

 

perfect!, cheers jonp!, and def like your suggestion too of updating container info for existing user containers when the docker template changes, this would of helped me out a few times in the past, as i added additional env vars and then had to talk users through manually adding it in.

Ok, yes definitely. That does happen when you are adding a new container with ports defined in the XML template. It appears that when you edit an existing container though, we let folks edit the container port. Probably shouldn't do that. Will discuss with Eric as this may just be a bug.

 

perfect!, cheers jonp!, and def like your suggestion too of updating container info for existing user containers when the docker template changes, this would of helped me out a few times in the past, as i added additional env vars and then had to talk users through manually adding it in.

So what should happen if a change you make to the master template conflicts with a user defined template setting?

  • Author

Ok, yes definitely. That does happen when you are adding a new container with ports defined in the XML template. It appears that when you edit an existing container though, we let folks edit the container port. Probably shouldn't do that. Will discuss with Eric as this may just be a bug.

 

perfect!, cheers jonp!, and def like your suggestion too of updating container info for existing user containers when the docker template changes, this would of helped me out a few times in the past, as i added additional env vars and then had to talk users through manually adding it in.

So what should happen if a change you make to the master template conflicts with a user defined template setting?

 

i think it should only add an entry if it doesnt exist, if there is a conflict it should skip, best not to annoy the end user by modifying an entry in the container, otherwise say you changed the placeholder text for the host path for the volume mapping to "please define me", and then pushed the change, in this scenario it would overwrite the existing host path and blow up the perfectly working container.

Ok, yes definitely. That does happen when you are adding a new container with ports defined in the XML template. It appears that when you edit an existing container though, we let folks edit the container port. Probably shouldn't do that. Will discuss with Eric as this may just be a bug.

 

perfect!, cheers jonp!, and def like your suggestion too of updating container info for existing user containers when the docker template changes, this would of helped me out a few times in the past, as i added additional env vars and then had to talk users through manually adding it in.

So what should happen if a change you make to the master template conflicts with a user defined template setting?

 

i think it should only add an entry if it doesnt exist, if there is a conflict it should skip, best not to annoy the end user by modifying an entry in the container, otherwise say you changed the placeholder text for the host path for the volume mapping to "please define me", and then pushed the change, in this scenario it would overwrite the existing host path and blow up the perfectly working container.

Can you put that in a feature request on the roadmap forum for me?  I will make sure it gets attention.

 

  • Author

Ok, yes definitely. That does happen when you are adding a new container with ports defined in the XML template. It appears that when you edit an existing container though, we let folks edit the container port. Probably shouldn't do that. Will discuss with Eric as this may just be a bug.

 

perfect!, cheers jonp!, and def like your suggestion too of updating container info for existing user containers when the docker template changes, this would of helped me out a few times in the past, as i added additional env vars and then had to talk users through manually adding it in.

So what should happen if a change you make to the master template conflicts with a user defined template setting?

 

i think it should only add an entry if it doesnt exist, if there is a conflict it should skip, best not to annoy the end user by modifying an entry in the container, otherwise say you changed the placeholder text for the host path for the volume mapping to "please define me", and then pushed the change, in this scenario it would overwrite the existing host path and blow up the perfectly working container.

Can you put that in a feature request on the roadmap forum for me?  I will make sure it gets attention.

 

sure i can jonp, no probs

Ok, yes definitely. That does happen when you are adding a new container with ports defined in the XML template. It appears that when you edit an existing container though, we let folks edit the container port. Probably shouldn't do that. Will discuss with Eric as this may just be a bug.

 

perfect!, cheers jonp!, and def like your suggestion too of updating container info for existing user containers when the docker template changes, this would of helped me out a few times in the past, as i added additional env vars and then had to talk users through manually adding it in.

So what should happen if a change you make to the master template conflicts with a user defined template setting?

 

i think it should only add an entry if it doesnt exist, if there is a conflict it should skip, best not to annoy the end user by modifying an entry in the container, otherwise say you changed the placeholder text for the host path for the volume mapping to "please define me", and then pushed the change, in this scenario it would overwrite the existing host path and blow up the perfectly working container.

Can you put that in a feature request on the roadmap forum for me?  I will make sure it gets attention.

 

sure i can jonp, no probs

Thanks bin! 

binhex, the same problem with sickbeard happened again.  I can no longer access it. 

 

I can see it running, since the following is a portion of the logs:

 

2015-06-27 04:39:39,045 DEBG 'sickbeard' stderr output:

04:39:39 INFO::SEARCHQUEUE-BACKLOG-255326 :: Finished searching for episodes from Defiance season 3

 

Something to note though, it's still 6/26 right now, but the date is advance.  I'm not sure if that has any implication.

 

What triggered the issue is, I tried to change the mapping for /data from /mnt/cache/.sickbeard to /mnt/user/Media/TV/.  After saving, it's no longer accessible. 

 

I hope to find out why this has happened.  So far, my experience with docker apps, only a few, has been pleasant except for sb.  Hope you can help troubleshoot.

 

btw, the ffg log came from unraid:

 

Jun 26 15:17:22 Tower avahi-daemon[4412]: Withdrawing workstation service for veth4bd563f.

Jun 26 15:17:22 Tower kernel: eth0: renamed from veth4bd563f

Jun 26 15:17:22 Tower php: binhex-sickbeard

Jun 26 15:17:37 Tower kernel: docker0: port 2(veth6b0db03) entered forwarding state

Jun 26 15:19:27 Tower kernel: docker0: port 2(veth6b0db03) entered disabled state

Jun 26 15:19:27 Tower kernel: device veth6b0db03 left promiscuous mode

Jun 26 15:19:27 Tower kernel: docker0: port 2(veth6b0db03) entered disabled state

Jun 26 15:19:27 Tower avahi-daemon[4412]: Withdrawing workstation service for veth6b0db03.

Jun 26 15:19:28 Tower kernel: device veth2031a32 entered promiscuous mode

Jun 26 15:19:28 Tower kernel: docker0: port 2(veth2031a32) entered forwarding state

Jun 26 15:19:28 Tower kernel: docker0: port 2(veth2031a32) entered forwarding state

Jun 26 15:19:28 Tower avahi-daemon[4412]: Withdrawing workstation service for vethe6fafcb.

Jun 26 15:19:28 Tower kernel: eth0: renamed from vethe6fafcb

Jun 26 15:19:38 Tower kernel: docker0: port 2(veth2031a32) entered disabled state

Jun 26 15:19:38 Tower kernel: device veth2031a32 left promiscuous mode

Jun 26 15:19:38 Tower kernel: docker0: port 2(veth2031a32) entered disabled state

Jun 26 15:19:38 Tower avahi-daemon[4412]: Withdrawing workstation service for veth2031a32.

Jun 26 15:19:39 Tower kernel: device vethe00b323 entered promiscuous mode

Jun 26 15:19:39 Tower kernel: docker0: port 2(vethe00b323) entered forwarding state

Jun 26 15:19:39 Tower kernel: docker0: port 2(vethe00b323) entered forwarding state

Jun 26 15:19:39 Tower avahi-daemon[4412]: Withdrawing workstation service for veth0d4a53a.

Jun 26 15:19:39 Tower kernel: docker0: port 2(vethe00b323) entered disabled state

Jun 26 15:19:39 Tower kernel: eth0: renamed from veth0d4a53a

Jun 26 15:19:39 Tower kernel: docker0: port 2(vethe00b323) entered forwarding state

Jun 26 15:19:39 Tower kernel: docker0: port 2(vethe00b323) entered forwarding state

Jun 26 15:19:51 Tower php: /usr/bin/docker stop binhex-sickbeard

Jun 26 15:19:54 Tower kernel: docker0: port 2(vethe00b323) entered forwarding state

Jun 26 15:20:01 Tower php: binhex-sickbeard

Jun 26 15:20:01 Tower kernel: docker0: port 2(vethe00b323) entered disabled state

Jun 26 15:20:01 Tower avahi-daemon[4412]: Withdrawing workstation service for vethe00b323.

Jun 26 15:20:01 Tower kernel: device vethe00b323 left promiscuous mode

Jun 26 15:20:01 Tower kernel: docker0: port 2(vethe00b323) entered disabled state

Jun 26 15:20:06 Tower php: /usr/bin/docker start binhex-sickbeard

Jun 26 15:20:06 Tower kernel: device veth2d42efb entered promiscuous mode

Jun 26 15:20:06 Tower avahi-daemon[4412]: Withdrawing workstation service for veth0dc165f.

Jun 26 15:20:06 Tower kernel: eth0: renamed from veth0dc165f

Jun 26 15:20:06 Tower kernel: docker0: port 2(veth2d42efb) entered forwarding state

Jun 26 15:20:06 Tower kernel: docker0: port 2(veth2d42efb) entered forwarding state

Jun 26 15:20:06 Tower php: binhex-sickbeard

Jun 26 15:20:10 Tower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1

Jun 26 15:20:21 Tower kernel: docker0: port 2(veth2d42efb) entered forwarding state

Jun 26 15:20:25 Tower emhttp: /usr/bin/tail -n 42 -f /var/log/syslog 2>&1

 

 

 

After my first install of sickbeard the log file is reporting it entered a fatal state..

http://pastebin.com/UmsmMKDb

 

Did I do something wrong?  ???

 

INFO gave up: sickbeard entered FATAL state, too many start retries too quickly

Archived

This topic is now archived and is closed to further replies.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.