Didstopia

The Minio container image still works fine, you just have to ensure that your data is on the main data array/pool and NOT on the cache pool. This is simply because Minio no longer works on BTRFS. The easiest fix is to create one or more array-only shares and use those instead, while of course also moving the data from the cache to the array, if necessary. See here for more information: https://github.com/minio/minio/issues/19181

Does Unraid's VNC break for anyone else after attempting to do this? virt-manager also crashes when trying to open a running a VM, which I'm assuming tries to initialize a new VNC connection, not sure if these two issues are related. Never mind. While I can't seem to connect with an external VNC client, I tried a different browser and it worked, so some kind of caching issue, which seems like the typical scenario when this happens. virt-manager still crashes, but that could just be because it's too old and the formula needs to be updated etc.

Or check my two messages above, which are likely the issue. 🙂

UPDATE: It worked! Here's the revised script, where I simply replaced all the hardcoded paths to login.php with an environment variable, then pointed said environment variable to the new/appropriate login page path. #!/bin/bash TYPE="retro-terminal" THEME="green.css" DOMAIN="theme-park.dev" #if you update the domain after the script has been run, You must disable and re enable JS or the whole theme. ADD_JS="true" JS="custom_text_header.js" DISABLE_THEME="false" #LOGIN_PAGE="/usr/local/emhttp/login.php" LOGIN_PAGE="/usr/local/emhttp/webGui/include/.login.php" echo -e "Variables set:\\n\ THEME = ${THEME}\\n\ DOMAIN = ${DOMAIN}\\n\ ADD_JS = ${ADD_JS}\\n\ JS = ${JS}\\n\ DISABLE_THEME = ${DISABLE_THEME}\\n" # Restore login.php if [ ${DISABLE_THEME} = "true" ]; then echo "Restoring backup of login.php" cp -p ${LOGIN_PAGE}.backup ${LOGIN_PAGE} exit 0 fi # Backup login page if needed. if [ ! -f ${LOGIN_PAGE}.backup ]; then echo "Creating backup of login.php" cp -p ${LOGIN_PAGE} ${LOGIN_PAGE}.backup fi # Use correct domain style case ${DOMAIN} in *"github.io"*) echo "Switching to github.io URL style" DOMAIN="${DOMAIN}\/theme.park" ;; esac # Adding stylesheets if ! grep -q ${DOMAIN} ${LOGIN_PAGE}; then echo "Adding stylesheet" sed -i -e "\@<style>@i\ <link rel='stylesheet' href='https://${DOMAIN}/css/addons/unraid/login-page/${TYPE}/${THEME}'>" ${LOGIN_PAGE} echo 'Stylesheet set to' ${THEME} fi # Adding/Removing javascript if [ ${ADD_JS} = "true" ]; then if ! grep -q ${JS} ${LOGIN_PAGE}; then if grep -q "<script type='text/javascript' src='https://${DOMAIN}/css/addons/unraid/login-page/" ${LOGIN_PAGE}; then echo "Replacing Javascript" sed -i "/<script type='text\/javascript' src='https:\/\/${DOMAIN}\/css\/addons\/unraid\/login-page/c <script type='text/javascript' src='https://${DOMAIN}/css/addons/unraid/login-page/${TYPE}/js/${JS}'></script>" ${LOGIN_PAGE} else echo "Adding javascript" sed -i -e "\@</body>@i\ <script type='text/javascript' src='https://${DOMAIN}/css/addons/unraid/login-page/${TYPE}/js/${JS}'></script>" ${LOGIN_PAGE} fi fi else if grep -q ${JS} ${LOGIN_PAGE}; then echo "Removing javascript.." sed -i "/<script type='text\/javascript' src='https:\/\/${DOMAIN}\/css\/addons\/unraid\/login-page/d" ${LOGIN_PAGE} fi fi # Changing stylesheet if ! grep -q ${TYPE}"/"${THEME} ${LOGIN_PAGE}; then echo "Changing existing custom stylesheet.." sed -i "/<link rel='stylesheet' href='https:\/\/${DOMAIN}\/css\/addons\/unraid\/login-page/c <link rel='stylesheet' href='https://${DOMAIN}/css/addons/unraid/login-page/${TYPE}/${THEME}'>" ${LOGIN_PAGE} echo 'Stylesheet set to' ${THEME} fi

Should this still be working? I'm on 6.10.0-rc2, however after the theme didn't seem to apply, I went digging and noticed something interesting about the login page itself. /usr/local/emhttp/login.php: <?php $docroot = $docroot ?? $_SERVER['DOCUMENT_ROOT'] ?: '/usr/local/emhttp'; require_once "$docroot/webGui/include/Helpers.php"; // add translations extract(parse_plugin_cfg('dynamix',true)); $login_locale = $display['locale']; require_once "$docroot/webGui/include/Translations.php"; $var = parse_ini_file('state/var.ini'); $error = ''; if ($_SERVER['REQUEST_URI'] == '/logout') { // User Logout if (isset($_COOKIE[session_name()])) { session_start(); unset($_SESSION['unraid_login']); unset($_SESSION['unraid_user']); // delete session file session_destroy(); // delete the session cookie $params = session_get_cookie_params(); setcookie(session_name(), '', 0, '/', $params['domain'], $params['secure'], isset($params['httponly'])); syslog(LOG_INFO, "Successfull logout user {$_SERVER['USER']} from {$_SERVER['REMOTE_ADDR']}"); } $error = _('Successfully logged out'); } $result = exec( "/usr/bin/passwd --status root"); if (($result === false) || (substr($result, 0, 6) !== "root P")) include "$docroot/webGui/include/.set-password.php"; else include "$docroot/webGui/include/.login.php"; ?> See how at the bottom it it's including ".login.php"? Well, it turns out that this is the file that actually includes all the HTML/CSS/JS, however I'm not sure when this change was made, especially considering others are on the same Unraid version, yet for some reason it's working for them. In the meantime I'll see if I can just substitute the paths for the new/different login page, as I would assume the structure/styling of the login page hasn't changed much, if at all.

Are there any plans to add ACL configuration to the plugin's web interface? In my case, iPXE doesn't play nice with LinuxIO/LIO, so I have to manually disable the ACL attribute `nopin_timeout` for every client, like so: echo 0 > /sys/kernel/config/target/iscsi/<target_iqn>/tpgt_1/acls/<client_iqn>/attrib/nopin_timeout

As Issues have been disabled for the GitHub repository, I'm no longer able to access or read them, but I looked through my emails and I'm assuming it was the one about harmless opcodes trying to read SMART data but failing due to it being a virtual disk/image? If so, that is very good to know, thank you. I can only assume, but my own research led me to this bug report, which seems to confirm it being a LIO (see message #28 in the bug report): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805252 Great, thank you. I unfortunately don't recall any other issue, other than the syslog spam caused by large amounts of files/writes. When possible, I will attempt to replicate the issue with FileIO and the latest version of this plugin, to confirm whether or not it still is an issue, or even if the issue was elsewhere (in iPXE for instance).

It might also be worth mentioning that the "Support Thread" link the plugin adds to Unraid doesn't actually link to here, but to the forum frontpage, which made me assume there was no support thread.

Hi Simon, it's Dids from GitHub. Just wanted to provide more details on this particular error: - Running on Unraid 6.9.2 - Using the iSCSI target plugin with FileIO images on the primary pool (HDD) - Attempting to install OS's, such as Windows 10, on the iSCSI target/FileIO image through iPXE, but the installation itself keeps failing and at the same time I see the FileIO errors in Unraid's syslog (found information via Google on "FileIO" and "FD_MAX_BYTES" that seemed to indicate it being a bug, which was already patched in newer versions) - When I dedicated an entire physical hard drive to iSCSI, it works as expected

In my case, it was caused by my 10GbE Aquantia NIC. Update its firmware to an "unofficial" one and it's been stable for days now. Used to crash once or twice per day before, with the similar calltrace as everyone else.

Sorry, should've mentioned it doesn't matter which Docker registry you're using. Just replace "your.repo.com" with your registry's URL, and the Docker CLI will attempt to log in to it. If you don't specify any registry, it'll default to logging in to Docker Hub (hub.docker.com). You can also login to multiple registries.

@mlebjerg

Yes, I have. In case it makes a difference, I'm dedicating a single network interface to Steamcache (eth2), which is statically set to 192.168.1.7 in unRAID's network settings, while the Docker container itself is found to 192.168.1.8.

I'm on 6.5.3, so I guess so?

I've been trying to setup Steamcache (and now SteamCacheBundle) on unRAID for a long, long time, but I've never gotten it to work. The issue I keep seeing is that the container itself doesn't seem to have internet connectivity, no matter what upstream DNS server I use. I've tried both a dedicated NIC and IP for the container, as well as bridged. Everything should be working, but it's not. It almost seems like it's able to resolve Steam-related DNS requests, and everything else is just dropped. Anyone else seeing the same? Any advice on what to try next?

Just to update on this, I just tried to do exactly this on the latest version of unRAID and got it working. First, ssh to the unRAID server as root. Next, run "docker login your.repo.com" (I also logged in to the Docker Hub, just because). Now run "cat ~/.docker/config.json", which should print out a bunch of JSON-formatted text. If it does, good, as this means it's now properly storing your Docker repository credentials for the root user. Finally, all that's left is to deploy a container from the web-interface, remembering to add your private repository url to the beginning of the image path.