Squid

BTW, you want the name changed for the repositories?

Odds on you changed the Container port of the app when you wanted to only change the Host port. Pretty much there is zero reason to ever change the container port, and doing so will generally break the app, hence the error.

My post count and time online according to profile don't tell the whole truth... I do (and will go down stating this) have a life outside of unRaid...

Because the appfeed is completely automated. Once the template exists in the repository, its added to CA

It should have removed the monitored files during uninstallation. *But*, it was possible for abandoned / orphaned bait files to have been created depending upon what was going on at the time. This should be fixed already on next rev. (Just tidying up some loose ends). The syslog when creating the files would actually have listed the orphaned files. Unfortunately not much you can do other than doing a search in Explorer for the file name and then deleting them there. Ahead of you there: (The Running section does change to indicate current status of creation / deletion)

It only chown. Might be worth a shot to do a chmod -R 755 on the data folder, just to rule it out. FWIW in my testing I deleted the config and data folders prior to switching between cache and user

Mount it using Unassigned Devices plugin, then add a volume mapping (mode: RW,Slave) pointing to the UD mount point

Nor I, although I don't particularly see how shfs would care about it. But either way, if it works as /mnt/cache, leave well enough alone

All cache only shares are also seen under /mnt/user. The only possibility I see and it doesn't make any sense is the format of the cache drive itself. Mine is XFS, what's yours?

So setting the /data path to /mnt/cache/docker/smokeping/ worked.. This is strange, as /mnt/user/docker/smokeping/ points to the same place and when inside the docker I could see /data and the files just fine? It's not really strange. /mnt/cache is a disk share and /mnt/user is a fuse (or how it's called) share. Support for hardlinking in user share is still new, so there might be some bugs still. Seems to work fine mapping both /data and /config to /mnt/user/.... running 6.3RC3 ie: No fault found, and since I don't believe there have been any changes since 6.2 RC4 (since the support for special unix files came into effect), I don't know what the issue may be...

ROFL. Make sure you point this out to him Sent from my LG-D852 using Tapatalk

MY EYES! MY EYES! The image, it burns. I wouldn't put anything beyond those two

Please ensure you post your results and don't forget to submit a bug report if necessary..... Sparklyballs is rubbing off on you. Not sure if that's a good thing or not... I did like you better before.[emoji14] Sent from my LG-D852 using Tapatalk

So setting the /data path to /mnt/cache/docker/smokeping/ worked.. This is strange, as /mnt/user/docker/smokeping/ points to the same place and when inside the docker I could see /data and the files just fine? It's not really strange. /mnt/cache is a disk share and /mnt/user is a fuse (or how it's called) share. Support for hardlinking in user share is still new, so there might be some bugs still. If its able to be replicated you guys really need to post defect reports about this kind of stuff so that Tom sees it Sent from my LG-D852 using Tapatalk Going to be have to be someone other than me as I'm around from home and had to powerdown my server as had an electrician round, would you believe the wimp needed to cut the power to the house, for some reason my server hasn't rebooted correctly, so I can't test. Just saying because my latest project relies upon hardlinks (i don't see any issues not with CA backup) and if there is one I'd really like it to be fixed Sent from my LG-D852 using Tapatalk Fancy testing smokeping? Fine.. You're my nemesis now. [emoji33] Sent from my LG-D852 using Tapatalk

So setting the /data path to /mnt/cache/docker/smokeping/ worked.. This is strange, as /mnt/user/docker/smokeping/ points to the same place and when inside the docker I could see /data and the files just fine? It's not really strange. /mnt/cache is a disk share and /mnt/user is a fuse (or how it's called) share. Support for hardlinking in user share is still new, so there might be some bugs still. If its able to be replicated you guys really need to post defect reports about this kind of stuff so that Tom sees it Sent from my LG-D852 using Tapatalk Going to be have to be someone other than me as I'm around from home and had to powerdown my server as had an electrician round, would you believe the wimp needed to cut the power to the house, for some reason my server hasn't rebooted correctly, so I can't test. Just saying because my latest project relies upon hardlinks (i don't see any issues not with CA backup) and if there is one I'd really like it to be fixed Sent from my LG-D852 using Tapatalk

So setting the /data path to /mnt/cache/docker/smokeping/ worked.. This is strange, as /mnt/user/docker/smokeping/ points to the same place and when inside the docker I could see /data and the files just fine? It's not really strange. /mnt/cache is a disk share and /mnt/user is a fuse (or how it's called) share. Support for hardlinking in user share is still new, so there might be some bugs still. If its able to be replicated you guys really need to post defect reports about this kind of stuff so that Tom sees it Sent from my LG-D852 using Tapatalk

Problem with extra bait files within normal shares is that it dramatically increases the odds of inadvertent tripping. You can always use the custom bait folder and toss as many files in there as you like. Next rev (couple days behind schedule) I'm using 200,000 bait files in specialized shares just for that purpose and leaving everything else with the stock 4 shares After the next rev I'm planning on switching the bait in normal shares from files to instead hardlinks which will let you instead run multiple copies without taking up an extra space (and might also speed up the response time by a milisecond or two) Sent from my LG-D852 using Tapatalk

Look in the docker FAQ for that error Sent from my LG-D852 using Tapatalk

Theres an entry in the docker FAQ about that message

Next rev states that... Just a little behind schedule due to real life

Only time ever seen network failure is when gateway is not set. Can you ping -c 3 github.com Sent from my LG-D852 using Tapatalk

Check your network settings. Probably no gateway is set Sent from my LG-D852 using Tapatalk

FIP makes use of inotifywait to monitor file changes. The command line looks something like this (depending on selected options): inotifywait -dsrqo /var/run/hash.pipe -e close_write --exclude ^/mnt/disk[0-9]+/files --format %w%f /mnt/disk1 /mnt/disk2 /mnt/disk3 ... This let inotifywait run as daemon and act only when (new) files are closed and push their name in a piped file, which on its turn is read and feed bunker to do the hash calculations and store the result in the extended attributes. Ps. changing extended attributes will not trigger a file change. Ok. That's why I wasn't getting and results from inotifywait. Because I'm looking at it on the user level and you're looking at it on the disk level. Wasn't worried about changes to the file but needed to know if you were triggering an attribute event (which is the only way to know if a hardlink to the file gets deleted) Sent from my LG-D852 using Tapatalk

Logs are saved when the script is run in the background or on a schedule. No log is captured if running in the foreground Sent from my LG-D852 using Tapatalk

Up to date lists of containers (for any repository) is within the All Applications Repositories / Support Threads Sticky (updated weekly - which includes any blacklisted apps of which a bunch of Sparklyballs' are because they've been deprecated in favour of the linuxserver versions), or within the Community Applications plugin (updated every 2 hours 24/7 - which won't ever display anything that's blacklisted) Probably half the authors here don't maintain their OPs with updated lists anymore because I'm able to do a better job at it with far less work.