binhex

hmm the output is a bit odd, can you post the entire report (obviously minus serial numbers).

im fairly ok with apps deleting their own temp files as this generally does happen without issue afaik, i also use /tmp to store temporary created files that store data that i need to share between users, for instance root and user nobody, for technical reasons in bash this gets difficult and thus i resort to use /tmp as a way of transferring critical information between acconts, its this temporary data that needs to be cleaned up and thus the historic cleaning of /tmp.

the difficulty is the cleanup code is in a general init script so no way of knowing what files are generated by any particular container and thus cleanup by name is...tricky, but not impossible i guess i could pass in the list of files to delete and inject that into the init script. yes that is possible, it would mean touching a fair chunk of code across multiple files in multiple repos to do this. i think for now i will go for a non recursive delete of /tmp and monitor for any rogue folders that might need to be included in the cleanup and add them in when necessary, its the least intrusive approach whilst preventing the issue from re-occurring.

if you had chosen any other folder other than /tmp for the container path then it wouldnt of happened, no. typically people create a folder in the container that doesnt normally exist, for example /media. so in that case you would have a host path of /mnt/user and a container path of /media and then you could use the application in the container to drill down through /media. i think as this has happened once, thats one too many times for my liking so i will alter the code to not be recursive, it will be a bit more tricky to ensure a clean folder but will stop this from accidentally happening again!

1) the reason it happened is because you mapped the root of your user shares (/mnt/user) to the /tmp directory in the container, mapping anything to /tmp is a VERY bad idea as youve found out, reason being that /tmp is used to store temporary files created during initialisation and creation of the vpn tunnel, and thus must be clear of all previous temporary files on startup and is duly wiped. 2) im assuming you have no backups right?, if not then you are into possible data recovery from either a 3rd party company or possibly a utility, im not the guy to speak about this so you are best off posting in the general section of the forum, whatever you do do NOT write anything to any of your disks, as this wil reduce your chances of recovery.

Check the contents of the ovpn file and make sure it has a 'remote' line defined Sent from my CLT-L09 using Tapatalk

No idea who 'djaydev' is but you need to either find his support thread and post your issue on there, or switch to the binhex krusader image. Sent from my CLT-L09 using Tapatalk

im waiting for upstream package maintainer on arch to update, once thats updated it will be auto built, link:- https://www.archlinux.org/packages/community/any/emby-server/

Alternative approach to changing to SeaBIOS or switching to Cirrus:- 1. mount iso for 'live cd' and boot vm 2. once you get to the grub menu press 'e' and append the following, failure to do this will mean you wont be able to boot to x windows:- systemd.mask=mhwd-live.service 3. press ctrl+x to save this change and the vm should boot. 4. once booted then install to vdisk and shutdown (do not reboot it will get stuck unmounting iso)- may require 'Force Stop' 5. once shutdown edit vm and remove the iso 6. start vm, this will get stuck at a black screen, you now need to press ctrl+alt+F2 in order to get to command prompt 7. login with root and the password you defined. 8. issue the following command to remove the symlink to mhwd - note this cannot be done at step 4. as the symlink does not exist sudo rm -f /etc/X11/xorg.conf.d/90-mhwd.conf && reboot 9. enjoy manjaro! - tested on 'cinnamon' and 'openbox' editions of manjaro.

sorry if my answer was a bit short, it was done on my mobile, i didnt mean for it to come across as curt, the answers above are much more detailed and should get you (or whoever) a good start to getting it included in CA.

A valid template in a repository watched by ca Sent from my CLT-L09 using Tapatalk

ok thanks for trying, it was a long shot 🙂

this looks like the obfuscation used for usenet downloads, its possible radarr is not able to correctly rename the folder after download and thus the folder stays named in its obfuscated format, im assuming the filename is correctly named though, right?.

ok so your config for the container, whilst a bit whacky (storing movies under a share named Plex?) looks ok, im assuming you have no networking issues on your home lan right?, so check dns resolution is working ok on the host, also just make sure your download rate looks ok, it probably will be but worth checking. can you try updating to the latest docker image?, there was a release for radarr that came out early this morning, it may fix your issue. one other thing to check, make sure your radarr config is being stored on the cache drive and not the array.

@jonathanm i dont suppose you would be kind enough to see if you can try this out? it might lead me to finding out what the underlying issue is, it sounds a bit odd but hey worth a go right?.