Everything posted by michielvv
-
Dockers using VPN network not rebuilding after update of VPN docker
Hi! I actually decided at some point to use "Rebuild-DNDC", which works like a charm. There is one catch where restarting the docker containers behind the VPN went orphan: the dockers behind the VPN mostly have ports explicitly configured. However, I have set Network Type to 'None' on those dockers. That is a combination that will not work (Docker will give you an error). The Unraid GUI seems to silently ignore those port settings when choosing the Network Type 'None' and successfully starts when pressing 'Apply'. Rebuild-DNDC will not and so tries to restart the docker with Network Type 'None' AND port configs. That fails. My solution was to remove the port configs from the dockers behind the VPN, so that Rebuild-DNDC successfully restarts those dockers with valid parameter combinations.
-
Dockers using VPN network not rebuilding after update of VPN docker
Thanks so much! I indeed think there may be some kind of race condition between the VPN connection complete and the rebuilding trigger for the VPN dependent dockers. << would this be a bug? The script works like a charm. I have followed the above instructions, renamed the PASSTHROUGHVPNNAME to the containernetwork named 'gluetunvpn'. It does work a little different from your explanation though: it just checks if the VPN container has been restarted based on uptime and container id change (if it cannot get the uptime it assumes a container restart). If so, then it will restart all containers that rely on the network of the VPN container. Simple and clean solution, nice!
-
Dockers using VPN network not rebuilding after update of VPN docker
anyone?
-
Dockers using VPN network not rebuilding after update of VPN docker
Hi all! Since a long time I have been looking for a solution for the following problem: I have several dockers that I want to have behind a VPN. To that purpose I have a GlueTun VPN docker. The other dockers are using the network of the VPN docker by adding special parameter "--net=container:gluetunvpn". This works like a charm. However, when the GlueTun VPN docker is updated or restarted, (obviously) the network of all depended dockers becomes invalid. After the restarting of the VPN docker, the depended dockers show 'Rebuild ready' but are stuck in that state. The only way that I am aware of to trigger the actual rebuilding of those dockers, is by browsing to the /docker overview in de WebUI. Once I do that, all these dockers start the actual rebuild. If I do not visit that URL, none of the dockers gets rebuild and remain stuck in their 'Rebuild ready' state. As such, part of my system becomes unresponsive as those dockers cannot be reached anymore. Is here any solution to this? Thanks in advance! Regards, Michiel
-
"Dashboard" section not showing anything (hanging load) - Gateway 504 errors
Thanks, noticed indeed in a parallel topic this might be the issue. Fixed it for me!
-
"Dashboard" section not showing anything (hanging load) - Gateway 504 errors
All, I have been using UnRaid to much happiness for some time, super! However, I now run into a problem after i did this: I removed my second parity drive and added that drive as new drive (disk clear, format). Then I invoked a manual move to get my cache drives emptied. After that, i can visit any other GUI part except for the Dashboard section. It tries loading and then at some time gives up and looks like this: If I open other 'tabs' of the gui in a separate tab in parallel, those pages give a gateway timeout 504. When the Dashboard section finally stops loading, i can load the other 'tabs' successfully, no problem. All docker, vms run, syslog reports no errors. A reboot did not fix it unfortunately... Diagnostics are attached! Any idea? Thanks in advance, Michiel nasi-diagnostics-20240306-1724.zip
-
Parity Check Tuning: ERROR: marker file found for both automatic and manual check P Q
Hi all! After an accidental power outage, Unraid boots and started its parity check. I checked the logs and noted the following: I cannot find any guidance on these errors (I searched at length, though maybe no good enough :)) - should I be concerned about these errors?
-
Re-arrange "data" user share with movies/series subfolders to multiple user shares (per subfolder)
This worked, thanks! I just tested it by moving /mnt/user/data/test-share to /mnt/user/test-share and indeed all files in this folder scattered over different drives and cache where moved in the background to the destination. Note that apparently SMB will restart, i.e. any SMB connection with the server will be reset.
-
Re-arrange "data" user share with movies/series subfolders to multiple user shares (per subfolder)
All, I am re-arranging my user shares from: data (< user share) Movies Series [whatever] into: Movies (< user share) Series (< user share) [whatever] (< user share) I have done extensive searching, but failed to find solid advise if this is as simple as mv command in /mnt/user/data to move all subfolders to /mnt/user/ which would *magically* align the (underlying) cache and disks folder structure? Reason to do it this way (instead of making new shares and moving data from the subfolder to the new shares) is that there is a lot of data to move. If I can prevent moving actual data by just changing the folder pointer, it could be done in a second. Maybe I need to manually change each folder structure on the cache and disks as well...? Anyways, I am afraid I somehow will wreck the disk/share framework Unraid is using and lose data, so looking for guidance. What would work? regards, Michiel
-
Update containers with custom network fails
Solved all of this: bottom line was that i implemented the wrong way of getting dockers to use the vpn docker's network instead of their own: 1. I made a custom network via the command line pointing to the VPN docker 2. in each of the docker's pull down lists I selected this network to use. This causes problems when updating (custom network does not seem to be refreshed with the new docker ID of the VPN docker) and portmapping problems somehow. Instead, I should've done the following: 1. for each docker, set network to 'none' 2. for each docker, add extra parameter "--net=container:[your vpn dockername - only lowercase allowed!!!]" And bingo: updating the vpn dockers refreshes the relying dockers automatically and portmapping is transparently working without errors. super!
-
Update containers with custom network fails
Thanks again for the help. Restarting of containers is then clear. The only challenge remaining is installing an update, which seems to apply the default template (with port mapping) rather than the one installed (without port mapping). Any clue how to solve that?
-
Update containers with custom network fails
Thanks for taking the time to debug this one! If i do what you suggest, it does solve the problem of the network restart loop (question b) indeed. The problem i do not solve is question c : how to update the other containers without port mapping (ie. this is what breaks restarting the updated container, it seems)? If i update the container, it will update, but fail to restart (due to the default port mapping). I have to remove the orphaned docker and reinstall the app from the docker templates section. There should be a way to update the container without the default port mapping....?
-
Update containers with custom network fails
any thoughts?
-
Update containers with custom network fails
Hi all! First of all: unraid rules. I enjoy using it every day and most 'challenges' I solve myself (and learn more tech as a bonus). Not so this one. I have setup gluetunvpn for a vpn connection. Then, I have configured a couple of containers to use the gluetunvpn network, so that all traffic will only flow through the gluetunvpn connection (ie. through the actual VPN connection). I have two challenges: 1) When i update the gluetunvpn container, the container:gluetunvpn networks used by the other containers become invalid. As a result, those other containers get stuck in a restart loop. I can understand that, as the container ID of gluetunvpn will change (hence, I assume, so does the network reference for each of the containers). 2) When i update any of the other containers that use the container:gluetunvpn they fail to restart, because by default there is a port mapping implemented, meant to be used in bridge/host network mode, but not in the case of container:gluetunvpn it seems. This is part of my setup: Three questions: a) I may not use the right implementation of networks to get what i need? is this the case and if so, what would be the preferred way? b) how to update gluetunvpn without getting the other containers in a restart loop? c) how to update the other containers without port mapping (ie. this is what breaks restarting the updated container, it seems)? Most grateful for your help!
-
[Support] MariaDB Official
Thanks, i know. Just want to be absolutely sure i do not somehow screw up the Nextcloud database, so used the docker convenience to separate those databases as much as possible
-
[Support] MariaDB Official
...and fixed it: my Nextcloud installation used /mnt/user/appdata/mariadb-official/ which is what the mariadb-official installer by default refers to. Because the Nextcloud Mysql is running, the filelock prevented havoc. My bad - though maybe an error as in 'data dir already exists!' or have the name of the data-dir rely on the name of the docker in Unraid would be convenient (though you might get other user errors )!
-
[Support] MariaDB Official
All, First of all: thanks for making the MariaDB docker available. Got a challenge though. Fresh out of the box (with the only change of port 3306 >> 3307 due to an existing MariaDB for nextcloud running on 3306 already) I get the following log with errors (and not working database): 2022-03-10 11:39:35+01:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:10.7.3+maria~focal started. 2022-03-10 11:39:36+01:00 [Note] [Entrypoint]: MariaDB upgrade information missing, assuming required 2022-03-10 11:39:36+01:00 [Note] [Entrypoint]: MariaDB upgrade (mariadb-upgrade) required, but skipped due to $MARIADB_AUTO_UPGRADE setting 2022-03-10 11:39:36 0 [Note] mariadbd (server 10.7.3-MariaDB-1:10.7.3+maria~focal) starting as process 1 ... 2022-03-10 11:39:36 0 [ERROR] mariadbd: Can't lock aria control file '/var/lib/mysql/aria_log_control' for exclusive use, error: 11. Will retry for 30 seconds 2022-03-10 11:40:06 0 [ERROR] mariadbd: Got error 'Could not get an exclusive lock; file is probably in use by another process' when trying to use aria control file '/var/lib/mysql/aria_log_control' 2022-03-10 11:40:06 0 [ERROR] Plugin 'Aria' init function returned error. 2022-03-10 11:40:06 0 [ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed. 2022-03-10 11:40:06 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2022-03-10 11:40:06 0 [Note] InnoDB: Number of transaction pools: 1 2022-03-10 11:40:06 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions 2022-03-10 11:40:06 0 [Note] InnoDB: Using Linux native AIO 2022-03-10 11:40:06 0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728 2022-03-10 11:40:06 0 [Note] InnoDB: Completed initialization of buffer pool 2022-03-10 11:40:06 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=33207616354,33207616354 2022-03-10 11:40:06 0 [ERROR] InnoDB: Malformed log record; set innodb_force_recovery=1 to ignore. 2022-03-10 11:40:06 0 [Note] InnoDB: Dump from the start of the mini-transaction (LSN=33207616354) to 100 bytes after the record: len 100; hex 66696c655f6c6f636b7302075052494d415259030473697a6500350206806c20bc270120063e590000033924df00205e0082b9030d070f20000120063ee0590000033924df096e657874636c6f75640d6f635f66696c655f6c6f636b73075052494d4152; asc file_locks PRIMARY size 5 l ' >Y 9$ ^ > Y 9$ nextcloud oc_file_locks PRIMAR; 2022-03-10 11:40:06 0 [Warning] InnoDB: Log scan aborted at LSN 33207681024 2022-03-10 11:40:06 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error 2022-03-10 11:40:06 0 [Note] InnoDB: Starting shutdown... 2022-03-10 11:40:06 0 [ERROR] Plugin 'InnoDB' init function returned error. 2022-03-10 11:40:06 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 2022-03-10 11:40:06 0 [Note] Plugin 'FEEDBACK' is disabled. 2022-03-10 11:40:06 0 [ERROR] Could not open mysql.plugin table: "Unknown storage engine 'Aria'". Some plugins may be not loaded 2022-03-10 11:40:06 0 [ERROR] Failed to initialize plugins. 2022-03-10 11:40:06 0 [ERROR] Aborting What does this mean and how to fix this? I have searched a lot and usually succeed, but I cannot solve this one... Thanks in advance!