3psus

Thanks for this, I've seen Portainer being used before and definitely liked my first impressions. My 2 cents as far as a GUI goes for docker compose: I'd really only be looking for a text field where I can copy/paste the YML content, which would then add that container to the unRaid containers management page, just like any other that would have been added using a template. I just feel that would be the natural way of doing things with docker in unRaid using compose, but that's just my personal impression. Been thinking about the Portainer option while writing this though, and I'm more and more inclined towards it. Thanks again!

Thx kubed! For those on 64bit system, this is the good package: http://packages.slackware.com/?r=slackware64-current&p=ncurses-6.0-x86_64-2.txz

thanks for the links above, tracked it back via github and arch already have the patch in place, i wondered why i wasnt seeing the issue Np! By the way, for anybody wanting to roll back, it is as easy as appending ":52" to the "Repository" field and update the container.

This seems to be related to curl. See notes for version 7.52.1_1 : https://www.freshports.org/ftp/curl and https://github.com/rakshasa/rtorrent/issues/538 I flagged the curl package out of date here so we can upgrade from apk as soon as possible : https://pkgs.alpinelinux.org/package/edge/main/x86/libcurl Edit: Also if we can get an update for the container with an upgraded curl, that would be awesome you flagged a package that is up to date with the latest release, as out of date ? you're going to be popular with alpine, lol. Yeah, you might be right. I actually thought there was a newer release of curl, but that is not the case. Anyways, it is done now, at least the maintainer will be notified about the issue and can apply the patch in a sub-release, like has been done on many other distros . I understand he might wait to the next stable release of curl though. I must say I find it surprising that libcurl hasn't had a new stable release after this but whatever. Thanks binhex for the suggestions. Seems like a roll back is the solution here. ref. https://github.com/curl/curl/issues/1174 https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/curl&id=bae58314ffe16b0642811fdb0187a9b8eba8d362 https://www.freshports.org/ftp/curl

This seems to be related to curl. See notes for version 7.52.1_1 : https://www.freshports.org/ftp/curl and https://github.com/rakshasa/rtorrent/issues/538 I flagged the curl package out of date here so we can upgrade from apk as soon as possible : https://pkgs.alpinelinux.org/package/edge/main/x86/libcurl Edit: Also if we can get an update for the container with an upgraded curl, that would be awesome

I've got the "Tracker: [Timeout was reached]" error also, but only for 2 trackers out of 5. This has appeared after last docker update, which also coordinates with a modem/router replacement (new model). Port forwarding seems fine, as reported by rutorrent. rtorrent version is not blacklisted on any of those trackers. Any ideas where this issue could come from?

Totally understand. So i'll just kill the Downloads usershare and move it to the Plex usershare, then all the links should work (correct me if I'm wrong). Thanks a lot!

I'm using cp -l /original/file /dest/file This file is located in a user share which has cache activated, but it is in fact from another user share: Downloads usershare to Plex usershare. I thought that it could work while the file was in the cache, but I understand that this is not possible.

no Thanks Squid, On 6.2.4, it seems I still cannot use hard links. Trying cp -l gives me the cross-device link error, and in CouchPotato, the option to link then fall back to copy will always result in a copy. If my understanding of the feature is correct, this should work right? If so, what should I investigate to solve the issue? Thanks

Good points. Yes hard links are now supported. Do we still need to do the changes from Page 1 to get hardlinks working in rc3?

Great answer Gary, huge thanks! Definitely turning turbo write on now.

I understand, thanks for the clarification. Streaming aside, would there be any noticeable impact on reads going on, wether it be in latency or in read speed? Or is it marginal to the point that it wouldn't be noticeable?

If you never spin down your disks, then this is likely to improve performance for writes. I feel like Scott's question deserve's a little more attention. From what Rob wrote, it seems like turbo write could worsen read operation currently going on while other disks are spun up, like when watching a movie. In my environment, disks are never spun down anyways so spinning them up for a small write isn't an issue. My main question is: if all disks are always spinning, am I going to be penalized in read operations if I turn turbo write on? Is the wait time mentioned in the movie example only caused by the time it takes for other disks to spin up or is there any other variables in play? Thanks for this great article Rob!

Believe it or not, it was Lastpass' autologin or autofill features that were breaking plexpy's settings page.

Thx for the app (Fix Common Problems) suggested. It did find issues wich I solved right away. After that, I decided to start from scratch. I created a new docker image, added the dockers with the same mappings except for plexpy, which I created a new directory in /mnt/cache/appdata/plexpy I then opened the webui and to my surprise, it still had the same settings with the same ID and password for webui authentication. I really am clueless about all of this. Where else does this docker keep it's info? After deleting the docker image and the /conf directory (for me /mnt/cache/appdata/plexpy), what else is there to delete?

Still have the same issue with latest updates. I have been able, after deleting and reinstalling multiple times (I think what solved it was to recreate the docker image), to get rid of those issues for a while but now with the latest plexpy update, same problems as stated in quoted post are back. What's up with that? I need enlightenment. Could somebody provide some guidance? Edit: To clarify, I just deleted the conainer and the image yet again and I am still presented first with the welcome page, then after restarting the docker, with a log in page that asks for the *same* user and password that was set *before* deleting everything.

+1 would love a Seafile docker as well

Hi people! Hopefully someone can help me. In the last days, I've had an issue with vnc where I cannot control the cursor in the vnc. It's as if my main cursor will go underneath the crashplan screen and I cannot move the vnc cursor, neither click. I can still use the keyboard though, and the vnc screen is definitely working. I have been using this docker for couple weeks with no issues before now. I should say that I recently had the cache ssd fail, which may have corrupted some data although I have not had any reason to believe so yet. Here are the logs from the docker, there are couple errors but I am not sure if they are relevant or not: Fri Aug 12 17:34:05 2016 Connections: closed: 127.0.0.1::47619 (Clean disconnection) EncodeManager: Framebuffer updates: 40 EncodeManager: Tight: EncodeManager: Solid: 45 rects, 3.46657 Mpixels EncodeManager: 720 B (1:19259.5 ratio) EncodeManager: Bitmap RLE: 8 rects, 1.706 kpixels EncodeManager: 312 B (1:22.1795 ratio) EncodeManager: Indexed RLE: 45 rects, 75.863 kpixels EncodeManager: 3.82129 KiB (1:77.6877 ratio) EncodeManager: Tight (JPEG): EncodeManager: Full Colour: 28 rects, 525.251 kpixels EncodeManager: 126.924 KiB (1:16.1679 ratio) EncodeManager: Total: 126 rects, 4.06939 Mpixels EncodeManager: 131.753 KiB (1:120.662 ratio) Terminating WebSockets proxy (137) _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/Tower:1 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root Xvnc TigerVNC 1.6.0 - built Dec 24 2015 16:05:46 Copyright (C) 1999-2015 TigerVNC Team and many others (see README.txt) See http://www.tigervnc.org for information on TigerVNC. Underlying X server release 11202000, The X.Org Foundation Fri Aug 12 17:34:21 2016 vncext: VNC extension running! vncext: Listening for VNC connections on all interface(s), port 4239 vncext: created VNC server for screen 0 Aug 12 17:34:21 Tower syslog-ng[40]: syslog-ng starting up; version='3.5.3' Warning: could not find self.pem Using local websockify at /opt/novnc/utils/websockify/run Starting webserver and WebSockets proxy on port 4280 Navigate to this URL: http://Tower:4280/vnc.html?host=Tower&port=4280

Just installed the docker and I am having difficulties with the settings page. First off, I generated a username and a password to access plexpy webui. I saved and restarted the container and all was good, username and password now showing in the webui. I went on changing some settings but as soon as I would save and restart the container, all changes had vanished. I could still see the username and password there, but anything that I changed after that didn't seem to be persistent. I tried to remove the username and password as a test, but when the container was restarted, they were still there in the settings page although plexpy didn't ask me to authenticate before loggin in. So the settings were saved but not persistent anymore in the webui. In config.ini, I can see all changes are registered. Last thing I tried was to delete the container and reinstall from scratch. To my surprise, as soon as i accessed the settings page for the first time, the first username and password that I had saved were still there. I have /logs mapped to /mnt/cache/appdata/plex/Library/Application Support/Plex Media Server/Logs/ and /config and /config mapped to /mnt/cache/appdata/plexpy/ Other than that, everytime I access the settings page, I get asked to backup the config file. Also, whe I click "check for update", I just get redirected to the main page. Everything else works as expected. Anybody else having those issues or knows what could be causing it? Thanks!