brando56894

Even though it looks like this will never happen, I'd like to be able to use iSCSI in my Windows 10 VM since it's better than SMB for remote storage.

Old habits die hard!

Ah good to know! In FreeNAS we had to do it all over again once you deleted the container.

Haha I know the feeling, I work in IT and have been a member of the FreeNAS forums (and other Linux forums) for years and usually do the same And yes I did change the title because it wasn't descriptive enough. I have 12 containers setup, so it would probably take like 5 minutes to setup all the paths and containers again, not a big deal but still something I would like to avoid if at all possible.

You completely missed the point of the post @Squid did you even read it? I changed the title because I'm assuming you just glanced at the title and went "ugh, silly noobs" and just copied that from your FAQ. I'm doing the exact opposite of that, this was due to me increasing the size to 50 GB using the method posted above when I was trying to figure out why my image was running out of space, and once I did I found out that my containers took up about 5 GB worth of space in the image, yet it was taking up 50 GB on my cache drive. Edit: you beat me to it haha

I couldn't find any information on how to resize the image without destroying the one currently used (which would require reinstalling all the containers). So I used my Google-fu to see if there was anything on the interwebs but couldn't find anything relating to images, just partitions, but I figured I'd give it a try since I had backed up the original. You can do the first two steps while the image is mounted and it doesn't matter is you specify the mount point (/var/lib/docker) or the image itself (/mnt/user/system/docker/docker.img) Step 1: Check the image's filesystem for errors btrfsck -p --repair /mnt/user/system/docker/docker.img Step 2: Resize the filesystem btrfs filesystem resize [new size] /mnt/user/system/docker/docker.img UNMOUNT THE IMAGE Step 3: Resize the image itself dd if=/mnt/user/system/docker/docker.img of=/mnt/user/system/docker/docker.img.new bs=2M count=6000 status=progress The above command will resize the image to 12 GB (2 MB block size, 6,000 blocks is about 12,000 MB/12 GB) Step 4: Make sure the image mounts mount /mnt/user/system/docker/docker.img.new /var/lib/docker; ls /var/lib/docker You should see the Docker filesystem in /var/lib/docker, now just unmount the image and either delete or rename the old docker.img and rename docker.img.new to docker.img and you're done!

I installed this on unRAID 6.4-RC7 and updated what was available, upon reboot the webGUI and libvirt were broken because php-fpm wouldn't start due to /usr/lib64/libunistring.so.2 missing. Removing this plugin resolved the issue.

This is what he's talking about, it just allows you to easily install unofficial plugins. I had no issues installing it. All I had to do was extract the zip file and drop it in my plug-ins folder via SMB and it worked instantly. Check you permissions.

Take a look at the logs /mnt/user/appdata/nextcloud/log/nginx/error.log and /mnt/user/appdata/nextcloud/log/php/error.log

I was going to post this in the defect reports section when I saw that someone had posted a similar issue to what I had experienced, but their issue was because of DirectIO, which I also have enabled. I asked that user to use /mnt/cache instead of /mnt/user and their issues were resolved as well

You just saved me from bashing my head against a wall for another few days. I couldn't figure out for the life of me why some of my containers suddenly wouldn't work. Any container that used SQLite would give tons of errors about the database being corrupted, but when I moved it to a location internal to the container it was fine. Switching the /config directory from /mnt/user to /mnt/cache solved all of my issues!

Can you please add the following to the FAQ, I just spent about 36 hours tackling it and no one here had an answer for me...even though the answer was buried in the Linuxserver.io Plex thread. When the appdata share is set to cache-only and the user (or container) sets the appdata path to /mnt/user/appdata instead of /mnt/cache/appdata FUSE freaks out and complains that all SQLite databases are corrupt, no matter what the container is or how many times you recreate the data. This seems to only affect SQLite since all files are written correctly, except that the SQLite databases are empty.

Even replacing the working SQlite database created in /root with the one in /config causes the same issues, so it's something with SQlite and Docker's transfer protocol that is causing the issues. Here's the errors from binhex-plexpass Jul 29, 2017 20:05:04.728 [0x2b2145d99700] INFO - Plex Media Server v1.7.6.4058-8fa494d15 - ubuntu PC x86_64 - build: linux-ubuntu-x86_64 redhat - GMT -04:00 Jul 29, 2017 20:05:04.728 [0x2b2145d99700] INFO - Linux version: 4.9.30-unRAID (#1 SMP PREEMPT Fri May 26 13:56:36 PDT 2017), language: en-GB Jul 29, 2017 20:05:04.728 [0x2b2145d99700] INFO - Processor Intel(R) Xeon(R) CPU D-1540 @ 2.00GHz Jul 29, 2017 20:05:04.728 [0x2b2145d99700] INFO - /opt/plexmediaserver/Plex Media Server Jul 29, 2017 20:05:04.726 [0x2b213a5856c0] DEBUG - BPQ: [Idle] -> [Starting] Jul 29, 2017 20:05:04.728 [0x2b213a5856c0] DEBUG - Opening 20 database sessions to library (com.plexapp.plugins.library), SQLite 3.13.0, threadsafe=1 Jul 29, 2017 20:05:04.729 [0x2b213a5856c0] ERROR - SQLITE3:0x10, 5386, os_unix.c:33579: (19) mmap(/config/Plex Media Server/Plug-in Support/Databases/com.plexapp.plugins.library.db-shm) - No such device Jul 29, 2017 20:05:04.729 [0x2b213a5856c0] ERROR - SQLITE3:0x10, 5386, disk I/O error Jul 29, 2017 20:05:04.730 [0x2b213a5856c0] ERROR - Database corruption: sqlite3_statement_backend::prepare: disk I/O error for SQL: PRAGMA cache_size=2000 Jul 29, 2017 20:05:04.730 [0x2b213a5856c0] ERROR - Error: Unable to set up server: sqlite3_statement_backend::prepare: disk I/O error for SQL: PRAGMA cache_size=2000 (N4soci10soci_errorE)

Yea my HBA decided to crap out for some reason when I was removing the 4x 1 TB drives. I have 8 drives that I wanted to use (7x 4 TB, 1x 512 GB SSD) but I only have 6 SATA ports, so I decided to disconnect and create a new config for the drives that only had data on them until I get my new motherboard on Thursday. Edit: I've tried switching to XFS for my cache drive, removing all of my docker containers, setting a share to only use one HDD and bypassing the cache 100%, and even trying three different Sonarr containers and got the same error every time!! Edit 2: It looks to be like it's an issue with the config directory...but it's not. I successfully DD'd an image (as root) from inside a container to the disk without an issue. I also started NzbDrone from within the container (as root) and pointed the config directory at /config and it crashed with the same error, but I pointed it at /root and it started without issue! root@9797b8b550f0:/# mono --debug /opt/NzbDrone/NzbDrone.exe -nobrowser -data=/root [Info] Bootstrap: Starting Sonarr - /opt/NzbDrone/NzbDrone.exe - Version 2.0.0.4855 [Info] AppFolderInfo: Data directory is being overridden to [/root] [Info] MigrationLogger: *** Migrating data source=/root/nzbdrone.db;cache size=-10485760;datetimekind=Utc;journal mode=Wal;pooling=True;version=3 *** [Info] MigrationLogger: *** VersionMigration migrating *** [Info] MigrationLogger: *** VersionUniqueMigration migrating *** [Info] MigrationLogger: *** VersionDescriptionMigration migrating *** [Info] MigrationLogger: *** 1: InitialSetup migrating *** [Info] InitialSetup: Starting migration to 1 [Info] MigrationLogger: *** 2: remove_tvrage_imdb_unique_constraint migrating *** [Info] remove_tvrage_imdb_unique_constraint: Starting migration to 2 [Info] MigrationLogger: *** 3: remove_renamed_scene_mapping_columns migrating *** [Info] remove_renamed_scene_mapping_columns: Starting migration to 3 [Info] MigrationLogger: *** 4: updated_history migrating *** [Info] updated_history: Starting migration to 4 [Info] MigrationLogger: *** 5: added_eventtype_to_history migrating *** [Info] added_eventtype_to_history: Starting migration to 5 [Info] MigrationLogger: *** 6: add_index_to_log_time migrating *** truncated....

Keep on forgetting to use that function since FreeNAS or vanilla Linux doesn't have something that easy haha Here ya go: tower-diagnostics-20170728-2010.zip