djvj

Yes it uses splitters. I'll check those then and see if it comes back up. Thank you

storinator-diagnostics-20250809-1004.zip Here you go

So what I was most afraid of happening has just occurred. During the rebuild, another disk just started dumping errors! Now I'm afraid of what to do as the rebuild is only 20% in?

So for the 3rd time, I rebooted and it did give me the start option after the parity-upgrade! So it's rebuilding now finally. Thanks for your help.

I think the only option now is to start again for a 3rd try? Maybe I should reboot first in case there is some bug going on?

I did change before I started. However, I just woke up and refreshed the page, so no I did not change anything since this last try.

Forgot to attach the diagnostics, sorry storinator-diagnostics-20250806-1347.zip

I can't start it though as these are my options. Note, I did not reboot or power cycle the server.

According to the docs, they have an example that sounds exactly like this: https://docs.unraid.net/unraid-os/manual/storage-management/#upgrading-parity-disks Parity SwapThis is a special case of replacing a disabled drive where the replacement drive is larger than your current parity drive. This procedure applies to both the parity1 and the parity2 drives. If you have dual parity then it can be used on both simultaneously to replace 2 disabled data drives with the 2 old parity drives. NOTE: It is not recommended that you use this procedure for upgrading the size of both a parity drive and a data drive as the array will be offline during the parity copy part of the operation. In such a case it is normally better to first upgrade the parity drive and then afterward upgrade the data drive using the drive replacement procedure. This takes longer but the array remains available for use throughout the process, and in addition, if anything goes wrong you have the just removed drive available intact for recovery purposes Why would you want to do this? To replace a data drive with a larger one, that is even larger than the Parity drive. Unraid does not require a replacement drive to be the same size as the drive being replaced. The replacement drive CANNOT be smaller than the old drive, but it CAN be larger, much larger in fact. If the replacement drive is the same size or larger, UP TO the same size as the smallest parity drive, then there the simple procedure above can be used. If the replacement drive is LARGER than the Parity drive, then a special two-step procedure is required as described here. It works in two phases: - The larger-than-existing-parity drive is first upgraded to become the new the parity drive - The old parity drive replaces the old data drive and the data of the failed drive is rebuilt onto it. As an example, you have a 1TB data drive that you want to replace (the reason does not matter). You have a 2TB parity drive. You buy a 4TB drive as a replacement. The 'Parity Swap' procedure will copy the parity info from the current 2TB parity drive to the 4TB drive, zero the rest, make it the new parity drive, then use the old 2TB parity drive to replace the 1TB data drive. Now you can do as you wish with the removed 1TB drive. I let it copy the parity to the drive a 2nd time and it did the same thing. It finished and got a log entry disk4 would be reconstructed and I don't see anything happening on the server and looks to be in the same state as before:

I have 2 failed drives (disk 1 and 4) at the same time in a dual-parity setup. My current parity was 18TB each. I bought 2 new 20TB drives. Put one in and after preclear, I assigned the new one in one of the parity spots and the old 18TB parity as a data disk 1 (one of the failed spots). Both of them shows a blue square and unraid let me do the parity upgrade. That took 2 days straight. It just complete and it wanted to start the array to do a data rebuild on one of the failed drives, but I wanted to start the rebuild on the drive that only had a few TBs used on it. So in the GUI I assigned the old 18TB drive to disk 4 and GUI wouldn't let me start it. So I assigned it back to the disk 1 spot but now it won't let me do anything again except it wants to start the parity upgrade all over again!! Nothing changed except assigning that old disk from 1 to 4 and back, I never touched the parity assignments at all and I don't want to start the same 2-day copy over again! Is this a bug that it thinks the parity is no longer good? I'm not sure what to do to avoid it starting the same exact parity upgrade process again? (I'm on v7.1.4)

Satisfactory just made a change to require a parameter sent to steamcmd to stay on the experimental brance. I don't see an ability to do that in the docker settings. How can I sent something like -steambeta to steamcmd? I tried setting this for the game parameters, but doesn't look like those are for steamcmd -beta experimental See more info here: https://satisfactory.fandom.com/wiki/Dedicated_servers#Experimental_Branch_Selection https://github.com/wolveix/satisfactory-server/pull/93

Trying to Install TinyMM and when I launch it I get this error: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker create --name='TinyMM' --net='bridge' -e TZ="America/New_York" -e HOST_OS="Unraid" -e 'USER_ID'='0' -e 'TZ'='America/NewYork' -e 'DISPLAY_HEIGHT'='1380' -e 'DISPLAY_WIDTH'='1200' -e 'PUID'='99' -e 'GUID'='100' -e 'UMASK'='000' -p '5801:5800/tcp' -p '5901:5900/tcp' -v '/mnt/user/Movies/':'/media/Movies':'rw' -v '/mnt/user/TV/':'/media/TV':'rw' -v '/mnt/user/TV2/':'/media/TV2':'rw' -v '/mnt/cache/appdata/TinyMM':'/config':'rw' 'coolasice1999/tmm:latest' 0ff7265bc2d05bc18c8d0deb00e671610d10a8398fc4fbaebb77c7505a4a4b2d Docker log won't show anything as it won't launch yet to start a log. I feel like I'm missing something simple, just can't see what. Compared to other docker settings, everything looks ok.. Anyone have an idea?

Just purchased a new 14TB WD Element drive and I've read others preclear before shucking. I just tried doing the same so I don't ruin the warranty in case it's a bad drive but when I start it, the script just gets stuck on Starting... I'm on unraid 6.9.2 and all plugins are updated. Is there something I need to do to get this to work?

That was it, thank you!!

When trying to delete large files, like multiple gigabyte files, they won't delete. But when I delete smaller files, they delete fine. I'm not sure what the cutoff is between the 2, but I'll try a 14GB file, and nothing happens when I try to delete it. A small txt file, and no problem, deletes fine. Permissions on everything are all 777. When I used the other krusader docker, I never had this issue. I only recently switch to this flavor because the other gave me too many issues. How can I figure out what's causing this?

Hello, just installed this docker and the log dumps this right after installation was complete. It keeps dumping it every few seconds and have no access to server or anything yet since it never actually started: Start Logitech Media Server... Can't call method "log" on an undefined value at /usr/share/squeezeboxserver/CPAN/Log/Log4perl/Appender.pm line 189. [19-06-04 22:40:57.0311] main::init (387) Starting Logitech Media Server (v7.9.2, 1555406898, Tue Apr 16 11:48:46 CEST 2019) perl 5.022001 - x86_64-linux-gnu-thread-multi [19-06-04 22:40:57.1204] Slim::Utils::SQLiteHelper::postConnect (374) Optimizing DB because of missing or empty sqlite_stat1 table [19-06-04 22:40:57.1308] Slim::Schema::forceCommit (2147) Warning: Trying to commit transactions before DB is initialized! [19-06-04 22:40:57.1844] Slim::Utils::SQLiteHelper::postConnect (374) Optimizing DB because of missing or empty sqlite_stat1 table [19-06-04 22:40:57.1948] Slim::Schema::forceCommit (2147) Warning: Trying to commit transactions before DB is initialized! [19-06-04 22:40:57.3892] Slim::Utils::SQLiteHelper::postConnect (374) Optimizing DB because of missing or empty sqlite_stat1 table [19-06-04 22:40:57.4000] Slim::Schema::forceCommit (2147) Warning: Trying to commit transactions before DB is initialized! It's been doing this for about 10 minutes, so didn't think it was still creating a db or anything. All settings in the docker template used were default. Ok nevermind. Restarting the docker seems to have fixed it. Hopes this helps if anyone else gets this error.

Thanks, I ended up having to recreate the grafana docker from scratch to fix. Hopefully it doesn't happen again.

Had this docker working great until the last update on either the Grafana docker, or the InfluxDB docker. Not sure which one broke it. But I get a "cannot write to readonly database" error when I try to start Grafana. Anyone have a clue? Log: t=2018-05-07T00:22:38-0400 lvl=info msg="Starting Grafana" logger=server version=5.1.0 commit=844bdc53a compiled=2018-04-26T11:09:23-0400 t=2018-05-07T00:22:38-0400 lvl=info msg="Config loaded from" logger=settings file=/usr/share/grafana/conf/defaults.ini t=2018-05-07T00:22:38-0400 lvl=info msg="Config loaded from" logger=settings file=/etc/grafana/grafana.ini t=2018-05-07T00:22:38-0400 lvl=info msg="Config overridden from command line" logger=settings arg="default.paths.data=/var/lib/grafana" t=2018-05-07T00:22:38-0400 lvl=info msg="Config overridden from command line" logger=settings arg="default.paths.logs=/var/log/grafana" t=2018-05-07T00:22:38-0400 lvl=info msg="Config overridden from command line" logger=settings arg="default.paths.plugins=/var/lib/grafana/plugins" t=2018-05-07T00:22:38-0400 lvl=info msg="Config overridden from command line" logger=settings arg="default.paths.provisioning=/etc/grafana/provisioning" t=2018-05-07T00:22:38-0400 lvl=info msg="Config overridden from command line" logger=settings arg="default.log.mode=console" t=2018-05-07T00:22:38-0400 lvl=info msg="Config overridden from Environment variable" logger=settings var="GF_PATHS_DATA=/var/lib/grafana" t=2018-05-07T00:22:38-0400 lvl=info msg="Config overridden from Environment variable" logger=settings var="GF_PATHS_LOGS=/var/log/grafana" t=2018-05-07T00:22:38-0400 lvl=info msg="Config overridden from Environment variable" logger=settings var="GF_PATHS_PLUGINS=/var/lib/grafana/plugins" t=2018-05-07T00:22:38-0400 lvl=info msg="Config overridden from Environment variable" logger=settings var="GF_PATHS_PROVISIONING=/etc/grafana/provisioning" t=2018-05-07T00:22:38-0400 lvl=info msg="Config overridden from Environment variable" logger=settings var="GF_SERVER_ROOT_URL=http://192.168.1.3" t=2018-05-07T00:22:38-0400 lvl=info msg="Config overridden from Environment variable" logger=settings var="GF_SECURITY_ADMIN_PASSWORD=*********" t=2018-05-07T00:22:38-0400 lvl=info msg="Path Home" logger=settings path=/usr/share/grafana t=2018-05-07T00:22:38-0400 lvl=info msg="Path Data" logger=settings path=/var/lib/grafana t=2018-05-07T00:22:38-0400 lvl=info msg="Path Logs" logger=settings path=/var/log/grafana t=2018-05-07T00:22:38-0400 lvl=info msg="Path Plugins" logger=settings path=/var/lib/grafana/plugins t=2018-05-07T00:22:38-0400 lvl=info msg="Path Provisioning" logger=settings path=/etc/grafana/provisioning t=2018-05-07T00:22:38-0400 lvl=info msg="App mode production" logger=settings t=2018-05-07T00:22:38-0400 lvl=info msg="Initializing DB" logger=sqlstore dbtype=sqlite3 t=2018-05-07T00:22:38-0400 lvl=info msg="Starting DB migration" logger=migrator t=2018-05-07T00:22:38-0400 lvl=info msg="Executing migration" logger=migrator id="copy data account to org" t=2018-05-07T00:22:38-0400 lvl=info msg="Skipping migration condition not fulfilled" logger=migrator id="copy data account to org" t=2018-05-07T00:22:38-0400 lvl=info msg="Executing migration" logger=migrator id="copy data account_user to org_user" t=2018-05-07T00:22:38-0400 lvl=info msg="Skipping migration condition not fulfilled" logger=migrator id="copy data account_user to org_user" t=2018-05-07T00:22:38-0400 lvl=info msg="Executing migration" logger=migrator id="create user auth table" t=2018-05-07T00:22:38-0400 lvl=eror msg="Executing migration failed" logger=migrator id="create user auth table" error="attempt to write a readonly database" t=2018-05-07T00:22:38-0400 lvl=eror msg="Exec failed" logger=migrator error="attempt to write a readonly database" sql="CREATE TABLE IF NOT EXISTS `user_auth` (\n`id` INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL\n, `user_id` INTEGER NOT NULL\n, `auth_module` TEXT NOT NULL\n, `auth_id` TEXT NOT NULL\n, `created` DATETIME NOT NULL\n);" t=2018-05-07T00:22:38-0400 lvl=eror msg="Fail to initialize orm engine" logger=sqlstore error="Sqlstore::Migration failed err: attempt to write a readonly database\n"

nuhll, I just started getting these as well!! Jan 25 12:24:03 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.12/2018-01-21 Jan 25 12:24:03 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.12/2018-01-22 Jan 25 12:24:03 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.12/2018-01-23 Jan 25 12:24:03 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.12/2018-01-24 Jan 25 12:24:04 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.12/2018-01-25 Jan 25 12:24:04 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.18/2018-01-21 Jan 25 12:24:04 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.18/2018-01-22 Jan 25 12:24:04 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.18/2018-01-23 Jan 25 12:24:04 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.18/2018-01-24 Jan 25 12:24:04 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.18/2018-01-25 Jan 25 12:29:03 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.12/2018-01-21 Jan 25 12:29:03 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.12/2018-01-22 Jan 25 12:29:03 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.12/2018-01-23 Jan 25 12:29:03 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.12/2018-01-24 Jan 25 12:29:03 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.12/2018-01-25 Jan 25 12:29:03 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.18/2018-01-21 Jan 25 12:29:03 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.18/2018-01-22 Jan 25 12:29:03 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.18/2018-01-23 Jan 25 12:29:03 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.18/2018-01-24 Jan 25 12:29:03 Storinator shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/disk2/Surveillance/Preview+Archive.18/2018-01-25

Thanks for the docker. Licensing had me confused for a bit but it ended up just working in the end.

Ah, that must be it, I don't have that as my repository. Thanks for your help.

If you are talking about the "clipboard observer", then yes that's enabled. I can't paste there nor when i click at the bottom to add a new link. In that next window I can't paste either.

Docker works fine, but I can't pass links from my clipboard into it. If I copy/paste within jdownloader in my chrome browser, it works fine. But copying say a link from notepad, it won't paste in. How can I fix this?

Ok I found the problem now. The issue is if you don't manually close the session with a quit command, it will remain open forever. This can happen if your browser crashes, or if you just click something else within the same window the session is on and leave the page. Following that thread, the PS command doesn't show ghost connections as suggested: root@Storinator:~# ps PID TTY TIME CMD 5446 pts/18 00:00:00 bash 5619 pts/18 00:00:00 ps So it's not really a bug with this plugin, but rather something not being handled that is caused by this plugin running in a window that so easily can be brought on. The w (who) command does show some idle sessions: root@Storinator:~# w 14:48:28 up 40 days, 21:22, 7 users, load average: 0.29, 0.28, 0.29 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root pts/0 tmux(28042).%0 21Nov16 39days 54:18 54:18 /usr/bin/rtorrent -n -o import=/config/rtorrent/rtorrent.rc root pts/1 tmux(28042).%3 23Nov16 38days 0.02s 0.02s -sh root pts/2 tmux(28042).%2 21Nov16 39days 0.02s 0.02s -sh root pts/10 tmux(28042).%4 27Nov16 34days 0.02s 0.02s -sh root pts/12 tmux(28042).%6 29Nov16 32days 0.02s 0.02s -sh root pts/5 tmux(28042).%7 29Nov16 31days 0.02s 0.02s -sh root pts/18 192.168.1.5 14:40 0.00s 0.00s 0.00s w 'who -aH' will list all processes taking up those precious pts/# slots: root@Storinator:~# who -aH NAME LINE TIME IDLE PID COMMENT EXIT 2016-11-20 17:26 1166 id=si term=0 exit=0 system boot 2016-11-20 17:26 run-level 3 2016-11-20 17:26 last=S 2016-11-20 17:27 1590 id=rc term=0 exit=0 LOGIN tty1 2016-11-20 17:27 9102 id=c1 LOGIN tty6 2016-11-20 17:27 9107 id=c6 LOGIN tty5 2016-11-20 17:27 9106 id=c5 LOGIN tty4 2016-11-20 17:27 9105 id=c4 LOGIN tty2 2016-11-20 17:27 9103 id=c2 LOGIN tty3 2016-11-20 17:27 9104 id=c3 pts/0 2016-11-21 18:52 15024 id=/0 term=0 exit=0 pts/1 2016-11-22 20:36 597 id=/1 term=0 exit=0 pts/4 2016-11-30 22:36 29951 id=/4 term=0 exit=0 pts/5 2016-11-21 19:58 30206 id=/5 term=0 exit=0 pts/7 2016-12-15 00:02 22223 id=ts/7 term=0 exit=0 pts/4 2016-11-21 19:27 13817 id=ts/4 term=0 exit=0 root + pts/0 2016-11-21 19:55 old 28042 (tmux(28042).%0) root + pts/1 2016-11-23 00:47 old 28042 (tmux(28042).%3) root + pts/2 2016-11-21 19:56 old 28042 (tmux(28042).%2) pts/7 2016-12-21 12:36 7776 id=/7 term=0 exit=0 pts/8 2016-12-05 22:48 18041 id=/8 term=0 exit=0 root + pts/10 2016-11-27 09:18 old 28042 (tmux(28042).%4) pts/11 2016-12-01 01:47 28042 id=s/11 term=0 exit=0 root + pts/12 2016-11-29 10:43 old 28042 (tmux(28042).%6) root + pts/5 2016-11-29 16:22 old 28042 (tmux(28042).%7) pts/3 2016-12-05 21:53 28257 id=/3 term=0 exit=0 pts/11 2016-12-06 16:23 17939 id=/11 term=0 exit=0 pts/13 2016-12-06 16:09 8025 id=/13 term=0 exit=0 pts/14 2016-12-08 09:45 19292 id=/14 term=0 exit=0 pts/14 2016-12-06 19:44 23597 id=s/14 term=0 exit=0 pts/15 2016-12-08 09:45 1166 id=s/15 term=0 exit=0 pts/16 2016-12-13 17:16 28141 id=/16 term=0 exit=0 pts/16 2016-12-09 10:14 22783 id=s/16 term=0 exit=0 pts/17 2016-12-08 23:51 6201 id=/17 term=0 exit=0 pts/18 2016-12-31 14:34 24454 id=/18 term=0 exit=0 pts/20 2016-12-31 14:42 16076 id=/20 term=0 exit=0 root + pts/18 2016-12-31 14:40 . 5446 (192.168.1.5) pts/19 2016-12-31 14:41 10815 id=/19 term=0 exit=0 To kill the active sessions, grab the PID from the above command and issue a kill on it: kill [PID] Now I can login again from this plugin. Would be nice if this plugin had some type of an ability to clear idle sessions.

I waited a few minutes and still nothing. I'll go back to the manual method instead. Hopefully this can be added to the docker officially one day as w/o it, this docker is only good for intranet git repos.