Niklas

You could try setting both PUID and GUID to 0. Please note that this will give the container full access to the file system (everything).

Set both "Container Variable: PUID" and "Container Variable: PGID" to 0

latest is v3 for me. I changed from preview to latest a couple of minutes after the docker build and page was updated. Sonarr was on version 3.0.5.1143 for preview and upgraded to 3.0.5.1144 when changed to latest. I did not remove the tag, I changed linuxserver/sonarr:preview to linuxserver/sonarr:latest and updated.

Strange. I switched from preview to latest without any problems.

It's fixed now. Update the container.

Not using MQTT (yet). I think it has something to do with networking. I don't know if this bug report could help

Far easier, yes. I knew I had that information somewhere locked away in my brain. Thanks for pointing that out! I just moved from docker.img to directory and added my 20 containers back using the add container button. Wasted some time there.

Also running home assistant. The most abuse I saw was writing to the home-assistant_v2.db (recorder/history). I moved home-assistant_v2.db from the btrfs cache to my unassigned hdd in 6.8.3. With the multiple cache pool support in 6.9, I removed unassigned devices and added the hdd as a second cache pool formatted as XFS. Just for use with stuff that writes lots of data to save some ssd life. No critical stuff.

Same time-zone as me. Yes, that what I said. You can try the "add container" button now before upgrading and you will probably see what I mean. Your dockers with settings will be in the "Template:" dropdown list (under "User templates").

57 days uptime without any problems. I just moved from docker.img to directory like three hours ago, running fine. As i understand, that command is not needed anymore with the 6.9-rc2. It only mitigates some of the writing amplifications but it's a start.

You don't need the solution mentioned there if running 6.9-rc2. In 6.9 you can select a dir to store your docker data instead of the docker.img (in the gui). You will lose all of your dockers but you can easily add them back with all your settings intact by using the "ADD CONTAINER" button. Select your docker from the "Template:" dropdown box and click apply.

Look in this report thread:

I have one ttyUSB0 also Edit And three ttyACMx

Same here. Broke all connections to my USB devices. You could try doing chmod 777 /dev/ttyACM0 in the server terminal and restart Domoticz. If it works, add the command to your go file.

Wondering the same thing, The version is getting quite old.

Just want to say that I used this script and it worked as expected. Thanks!

I add some trackers using the "Automatically add these trackers to new downloads" but that setting and field reset when restarting the container. In qBittorrent.conf: Bittorrent\AddTrackers=true Bittorrent\TrackersList=udp://tracker.example.com:669/announce\nudp://tracker2.example.com:699/announce After container restart Bittorrent\AddTrackers=false Bittorrent\TrackersList= Edit: This could of course be a problem with qbittorrent itself. hmm.

I would guess this container is missing the required dependencies to make the built in version work. Also guessing it has something to do with Alpine.

Yes. I tried three different locations. /mnt/cache/appdata, /mnt/user/appdata (set to cache only) and /mnt/user/arraydata (array only). The two first locations generate that crazy 12-20GB/h. On array, it was like 10x+ less writing. The loop device also does some writing I find strange, yes. Wrote about this before noticing the high mariadb usage.. I will read your bug report and answers. Edit: this is just by keeping an eye on mariadb specifically. Other containers writing to the appdata dir will probably also generate lots of waste data including the loopback docker.img.

loop2 is the mounted docker.img, right? I have it pointed to /mnt/cache/system/docker/docker.img What did you change in your rc.docker?

Running MariaDB-docker pointed to /mnt/cache/appdata/mariadb or /mnt/user/appdata/mariadb (Use cache: Only) generates LOTS of writes to the cache drive(s). Between 15-20GB/h. iotop showing almost all that writing consumed by mariadb. Moving the databases to array, the writes goes down very much (using "iotop -ao"). I use MariaDB for light use of Nextcloud and Home Assistant. Nothing else. This is iotop for an hour with mariadb databases on cache drive. /mnt/cache/appdata or /mnt/user/appdata with cache only: When /mnt/cache/appdata is used, the shfs-processes will show as mysql(d?). Missing screenshot. This is iotop for about an hour with databases on array. /mnt/user/araydata: Still a bit much (seen to my light usage) but not even near the writing when on cache. I don't know if this is a bug in Unraid, btrfs or something but I will keep my databases on array to save some ssd life. I will loose speed but as I said, this is with very light use of mariadb.. I checked tree different ways to enter the path to the location for databases (/config) and let it sit for an hour with freshly started iotop between the different paths. To calculate data used, I checked and compared the smart value "233 Lifetime wts to flsh GB" for the ssd(s). Running mirrored drives. I guess other stuff writing to the cache drive or share with cache set to only will have unnecessary high writes. Sorry for my rumble. I get like that when I'm interested in a specific area. Not native english speaker. Please, just ask if unclear. Edit: My docs On /mnt/cache/appdata/mariadb (direct cache drive) 2020-02-08 kl 22:02 - 23:04. 15 (!) GB written. On /mnt/user/arraydata/mariadb (user share on array only) 2020-02-08 kl 23:04-00:02. 2 GB written. On /mnt/user/appdata/mariadb (Use cache: Only) 2020-02-09 kl 00:02-01:02. 22 GB (!) written. Just ran this again to really see the differense and loook attt itttt. On /mnt/user/arraydata/mariadb (array only, spinning rust) 2020-02-09 kl 01:02-02:02. 4 GB written.

Change both PUID and PGID to 0 in the settings for the container.

"php7" missing in the command. sudo -u abc php7 /config/www/nextcloud/occ db:convert-filecache-bigint

For ONLYOFFICE. With Hub (18) you install the ONLYOFFICE connector and after that, search for "Community Document Server" within Nextcloud - Apps and install that. https://apps.nextcloud.com/apps/documentserver_community Does not work for me. Only gives me "Community document server is not supported for this instance, please setup and configure an external document server" Tried chmod for the files mentioned here https://github.com/nextcloud/documentserver_community/issues/10 with no luck. Guess I have to wait and see how this develops.

And you are only changing the host port? Not the container port?