jademonkee

My weekly backup ran this morning, so it shut all my Dockers down at 5am. However, now mongodb is refusing to start. I have no idea why. {"t":{"$date":"2024-01-10T05:00:39.718+00:00"},"s":"I", "c":"CONTROL", "id":23377, "ctx":"SignalHandler","msg":"Received signal","attr":{"signal":15,"error":"Terminated"}} {"t":{"$date":"2024-01-10T05:00:39.718+00:00"},"s":"I", "c":"CONTROL", "id":23378, "ctx":"SignalHandler","msg":"Signal was sent by kill(2)","attr":{"pid":0,"uid":0}} {"t":{"$date":"2024-01-10T05:00:39.718+00:00"},"s":"I", "c":"CONTROL", "id":23381, "ctx":"SignalHandler","msg":"will terminate after current cmd ends"} {"t":{"$date":"2024-01-10T05:00:39.734+00:00"},"s":"I", "c":"REPL", "id":4784900, "ctx":"SignalHandler","msg":"Stepping down the ReplicationCoordinator for shutdown","attr":{"waitTimeMillis":10000}} {"t":{"$date":"2024-01-10T05:00:39.902+00:00"},"s":"I", "c":"COMMAND", "id":4784901, "ctx":"SignalHandler","msg":"Shutting down the MirrorMaestro"} {"t":{"$date":"2024-01-10T05:00:39.902+00:00"},"s":"I", "c":"SHARDING", "id":4784902, "ctx":"SignalHandler","msg":"Shutting down the WaitForMajorityService"} {"t":{"$date":"2024-01-10T05:00:39.902+00:00"},"s":"I", "c":"CONTROL", "id":4784903, "ctx":"SignalHandler","msg":"Shutting down the LogicalSessionCache"} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"I", "c":"NETWORK", "id":20562, "ctx":"SignalHandler","msg":"Shutdown: going to close listening sockets"} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"I", "c":"NETWORK", "id":23017, "ctx":"listener","msg":"removing socket file","attr":{"path":"/tmp/mongodb-27017.sock"}} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"W", "c":"NETWORK", "id":23022, "ctx":"listener","msg":"Unable to remove UNIX socket","attr":{"path":"/tmp/mongodb-27017.sock","error":"Operation not permitted"}} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"I", "c":"NETWORK", "id":4784905, "ctx":"SignalHandler","msg":"Shutting down the global connection pool"} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"I", "c":"STORAGE", "id":4784906, "ctx":"SignalHandler","msg":"Shutting down the FlowControlTicketholder"} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"I", "c":"-", "id":20520, "ctx":"SignalHandler","msg":"Stopping further Flow Control ticket acquisitions."} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"I", "c":"STORAGE", "id":4784908, "ctx":"SignalHandler","msg":"Shutting down the PeriodicThreadToAbortExpiredTransactions"} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"I", "c":"STORAGE", "id":4784934, "ctx":"SignalHandler","msg":"Shutting down the PeriodicThreadToDecreaseSnapshotHistoryCachePressure"} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"I", "c":"REPL", "id":4784909, "ctx":"SignalHandler","msg":"Shutting down the ReplicationCoordinator"} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"I", "c":"SHARDING", "id":4784910, "ctx":"SignalHandler","msg":"Shutting down the ShardingInitializationMongoD"} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"I", "c":"REPL", "id":4784911, "ctx":"SignalHandler","msg":"Enqueuing the ReplicationStateTransitionLock for shutdown"} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"I", "c":"-", "id":4784912, "ctx":"SignalHandler","msg":"Killing all operations for shutdown"} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"I", "c":"-", "id":4695300, "ctx":"SignalHandler","msg":"Interrupted all currently running operations","attr":{"opsKilled":5}} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"I", "c":"COMMAND", "id":4784913, "ctx":"SignalHandler","msg":"Shutting down all open transactions"} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"I", "c":"REPL", "id":4784914, "ctx":"SignalHandler","msg":"Acquiring the ReplicationStateTransitionLock for shutdown"} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"I", "c":"INDEX", "id":4784915, "ctx":"SignalHandler","msg":"Shutting down the IndexBuildsCoordinator"} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"I", "c":"REPL", "id":4784916, "ctx":"SignalHandler","msg":"Reacquiring the ReplicationStateTransitionLock for shutdown"} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"I", "c":"REPL", "id":4784917, "ctx":"SignalHandler","msg":"Attempting to mark clean shutdown"} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"I", "c":"NETWORK", "id":4784918, "ctx":"SignalHandler","msg":"Shutting down the ReplicaSetMonitor"} {"t":{"$date":"2024-01-10T05:00:39.903+00:00"},"s":"I", "c":"SHARDING", "id":4784921, "ctx":"SignalHandler","msg":"Shutting down the MigrationUtilExecutor"} {"t":{"$date":"2024-01-10T05:00:39.904+00:00"},"s":"I", "c":"NETWORK", "id":22944, "ctx":"conn3","msg":"Connection ended","attr":{"remote":"172.19.0.3:45170","connectionId":3,"connectionCount":5}} {"t":{"$date":"2024-01-10T05:00:39.904+00:00"},"s":"I", "c":"NETWORK", "id":22944, "ctx":"conn1","msg":"Connection ended","attr":{"remote":"172.19.0.3:45152","connectionId":1,"connectionCount":4}} {"t":{"$date":"2024-01-10T05:00:39.904+00:00"},"s":"I", "c":"STORAGE", "id":4784927, "ctx":"SignalHandler","msg":"Shutting down the HealthLog"} {"t":{"$date":"2024-01-10T05:00:39.904+00:00"},"s":"I", "c":"STORAGE", "id":4784929, "ctx":"SignalHandler","msg":"Acquiring the global lock for shutdown"} {"t":{"$date":"2024-01-10T05:00:39.904+00:00"},"s":"I", "c":"STORAGE", "id":4784930, "ctx":"SignalHandler","msg":"Shutting down the storage engine"} {"t":{"$date":"2024-01-10T05:00:39.904+00:00"},"s":"I", "c":"STORAGE", "id":22320, "ctx":"SignalHandler","msg":"Shutting down journal flusher thread"} {"t":{"$date":"2024-01-10T05:00:39.904+00:00"},"s":"I", "c":"STORAGE", "id":22321, "ctx":"SignalHandler","msg":"Finished shutting down journal flusher thread"} {"t":{"$date":"2024-01-10T05:00:39.904+00:00"},"s":"I", "c":"STORAGE", "id":20282, "ctx":"SignalHandler","msg":"Deregistering all the collections"} {"t":{"$date":"2024-01-10T05:00:39.904+00:00"},"s":"I", "c":"NETWORK", "id":22944, "ctx":"conn160","msg":"Connection ended","attr":{"remote":"172.19.0.3:35476","connectionId":160,"connectionCount":3}} {"t":{"$date":"2024-01-10T05:00:39.904+00:00"},"s":"I", "c":"NETWORK", "id":22944, "ctx":"conn106","msg":"Connection ended","attr":{"remote":"172.19.0.3:50332","connectionId":106,"connectionCount":2}} {"t":{"$date":"2024-01-10T05:00:39.910+00:00"},"s":"I", "c":"STORAGE", "id":22261, "ctx":"SignalHandler","msg":"Timestamp monitor shutting down"} {"t":{"$date":"2024-01-10T05:00:39.910+00:00"},"s":"I", "c":"STORAGE", "id":22317, "ctx":"SignalHandler","msg":"WiredTigerKVEngine shutting down"} {"t":{"$date":"2024-01-10T05:00:39.910+00:00"},"s":"I", "c":"STORAGE", "id":22318, "ctx":"SignalHandler","msg":"Shutting down session sweeper thread"} {"t":{"$date":"2024-01-10T05:00:39.910+00:00"},"s":"I", "c":"STORAGE", "id":22319, "ctx":"SignalHandler","msg":"Finished shutting down session sweeper thread"} {"t":{"$date":"2024-01-10T05:00:39.910+00:00"},"s":"I", "c":"STORAGE", "id":22322, "ctx":"SignalHandler","msg":"Shutting down checkpoint thread"} {"t":{"$date":"2024-01-10T05:00:39.911+00:00"},"s":"I", "c":"STORAGE", "id":22323, "ctx":"SignalHandler","msg":"Finished shutting down checkpoint thread"} {"t":{"$date":"2024-01-10T05:00:39.913+00:00"},"s":"I", "c":"STORAGE", "id":4795902, "ctx":"SignalHandler","msg":"Closing WiredTiger","attr":{"closeConfig":"leak_memory=true,"}} {"t":{"$date":"2024-01-10T05:00:39.925+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"SignalHandler","msg":"WiredTiger message","attr":{"message":"[1704862839:925143][1:0x15274134b700], close_ckpt: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 343738, snapshot max: 343738 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 660"}} {"t":{"$date":"2024-01-10T05:00:39.957+00:00"},"s":"I", "c":"STORAGE", "id":4795901, "ctx":"SignalHandler","msg":"WiredTiger closed","attr":{"durationMillis":44}} {"t":{"$date":"2024-01-10T05:00:39.957+00:00"},"s":"I", "c":"STORAGE", "id":22279, "ctx":"SignalHandler","msg":"shutdown: removing fs lock..."} {"t":{"$date":"2024-01-10T05:00:39.957+00:00"},"s":"I", "c":"-", "id":4784931, "ctx":"SignalHandler","msg":"Dropping the scope cache for shutdown"} {"t":{"$date":"2024-01-10T05:00:39.957+00:00"},"s":"I", "c":"FTDC", "id":4784926, "ctx":"SignalHandler","msg":"Shutting down full-time data capture"} {"t":{"$date":"2024-01-10T05:00:39.957+00:00"},"s":"I", "c":"FTDC", "id":20626, "ctx":"SignalHandler","msg":"Shutting down full-time diagnostic data capture"} {"t":{"$date":"2024-01-10T05:00:39.964+00:00"},"s":"I", "c":"CONTROL", "id":20565, "ctx":"SignalHandler","msg":"Now exiting"} {"t":{"$date":"2024-01-10T05:00:39.964+00:00"},"s":"I", "c":"CONTROL", "id":23138, "ctx":"SignalHandler","msg":"Shutting down","attr":{"exitCode":0}} {"t":{"$date":"2024-01-10T05:08:05.056+00:00"},"s":"I", "c":"CONTROL", "id":23285, "ctx":"main","msg":"Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'"} {"t":{"$date":"2024-01-10T05:08:05.062+00:00"},"s":"I", "c":"NETWORK", "id":4648601, "ctx":"main","msg":"Implicit TCP FastOpen unavailable. If TCP FastOpen is required, set tcpFastOpenServer, tcpFastOpenClient, and tcpFastOpenQueueSize."} {"t":{"$date":"2024-01-10T05:08:05.062+00:00"},"s":"I", "c":"STORAGE", "id":4615611, "ctx":"initandlisten","msg":"MongoDB starting","attr":{"pid":1,"port":27017,"dbPath":"/data/db","architecture":"64-bit","host":"1211a40e6d4a"}} {"t":{"$date":"2024-01-10T05:08:05.062+00:00"},"s":"I", "c":"CONTROL", "id":23403, "ctx":"initandlisten","msg":"Build Info","attr":{"buildInfo":{"version":"4.4.27","gitVersion":"2da9e4437d8c792c2b3c3aea62e284f801172a6b","openSSLVersion":"OpenSSL 1.1.1f 31 Mar 2020","modules":[],"allocator":"tcmalloc","environment":{"distmod":"ubuntu2004","distarch":"x86_64","target_arch":"x86_64"}}}} {"t":{"$date":"2024-01-10T05:08:05.062+00:00"},"s":"I", "c":"CONTROL", "id":51765, "ctx":"initandlisten","msg":"Operating System","attr":{"os":{"name":"Ubuntu","version":"20.04"}}} {"t":{"$date":"2024-01-10T05:08:05.062+00:00"},"s":"I", "c":"CONTROL", "id":21951, "ctx":"initandlisten","msg":"Options set by command line","attr":{"options":{"net":{"bindIp":"*"}}}} {"t":{"$date":"2024-01-10T05:08:05.063+00:00"},"s":"E", "c":"NETWORK", "id":23024, "ctx":"initandlisten","msg":"Failed to unlink socket file","attr":{"path":"/tmp/mongodb-27017.sock","error":"Operation not permitted"}} {"t":{"$date":"2024-01-10T05:08:05.063+00:00"},"s":"F", "c":"-", "id":23091, "ctx":"initandlisten","msg":"Fatal assertion","attr":{"msgid":40486,"file":"src/mongo/transport/transport_layer_asio.cpp","line":1048}} {"t":{"$date":"2024-01-10T05:08:05.063+00:00"},"s":"F", "c":"-", "id":23092, "ctx":"initandlisten","msg":"\n\n***aborting after fassert() failure\n\n"} {"t":{"$date":"2024-01-10T11:11:41.977+00:00"},"s":"I", "c":"CONTROL", "id":23285, "ctx":"main","msg":"Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'"} {"t":{"$date":"2024-01-10T11:11:41.979+00:00"},"s":"I", "c":"NETWORK", "id":4648601, "ctx":"main","msg":"Implicit TCP FastOpen unavailable. If TCP FastOpen is required, set tcpFastOpenServer, tcpFastOpenClient, and tcpFastOpenQueueSize."} {"t":{"$date":"2024-01-10T11:11:41.980+00:00"},"s":"I", "c":"STORAGE", "id":4615611, "ctx":"initandlisten","msg":"MongoDB starting","attr":{"pid":1,"port":27017,"dbPath":"/data/db","architecture":"64-bit","host":"1211a40e6d4a"}} {"t":{"$date":"2024-01-10T11:11:41.980+00:00"},"s":"I", "c":"CONTROL", "id":23403, "ctx":"initandlisten","msg":"Build Info","attr":{"buildInfo":{"version":"4.4.27","gitVersion":"2da9e4437d8c792c2b3c3aea62e284f801172a6b","openSSLVersion":"OpenSSL 1.1.1f 31 Mar 2020","modules":[],"allocator":"tcmalloc","environment":{"distmod":"ubuntu2004","distarch":"x86_64","target_arch":"x86_64"}}}} {"t":{"$date":"2024-01-10T11:11:41.980+00:00"},"s":"I", "c":"CONTROL", "id":51765, "ctx":"initandlisten","msg":"Operating System","attr":{"os":{"name":"Ubuntu","version":"20.04"}}} {"t":{"$date":"2024-01-10T11:11:41.980+00:00"},"s":"I", "c":"CONTROL", "id":21951, "ctx":"initandlisten","msg":"Options set by command line","attr":{"options":{"net":{"bindIp":"*"}}}} {"t":{"$date":"2024-01-10T11:11:41.980+00:00"},"s":"E", "c":"NETWORK", "id":23024, "ctx":"initandlisten","msg":"Failed to unlink socket file","attr":{"path":"/tmp/mongodb-27017.sock","error":"Operation not permitted"}} {"t":{"$date":"2024-01-10T11:11:41.980+00:00"},"s":"F", "c":"-", "id":23091, "ctx":"initandlisten","msg":"Fatal assertion","attr":{"msgid":40486,"file":"src/mongo/transport/transport_layer_asio.cpp","line":1048}} {"t":{"$date":"2024-01-10T11:11:41.980+00:00"},"s":"F", "c":"-", "id":23092, "ctx":"initandlisten","msg":"\n\n***aborting after fassert() failure\n\n"} I did remove the .js file, as well as the Docker's path to it. But that's only used the first time it runs, right? I can't think of any other changes I have made. Any idea what's going on? Why would there be a permission error in the tmp dir? Really tempted to move over to PeteA's all in one Docker now...

I speak too soon: it did not stop the logging...

Thanks for the info. FWIW I opened a terminal to the mongodb container and entered mongod --quiet to stop the logging. If anything goes wrong, I guess I'll turn the logging back on, but for the moment I don't really need it (hopefully that's not naive of me 😅)

Just moved over to the two-container solution using a combination of the instructions from LS.IO and in this thread. Everything seems to be working fine now, except that my mongodb log is constantly being written to with entries like the following: {"t":{"$date":"2024-01-05T15:59:22.000+00:00"},"s":"I", "c":"NETWORK", "id":51800, "ctx":"conn12","msg":"client metadata","attr":{"remote":"172.19.0.3:50624","client":"conn12","doc":{"driver":{"name":"mongo-java-driver|sync","version":"4.6.1"},"os":{"type":"Linux","name":"Linux","architecture":"amd64","version":"6.1.64-Unraid"},"platform":"Java/Private Build/17.0.9+9-Ubuntu-122.04"}}} {"t":{"$date":"2024-01-05T15:59:22.052+00:00"},"s":"I", "c":"ACCESS", "id":20250, "ctx":"conn12","msg":"Authentication succeeded","attr":{"mechanism":"SCRAM-SHA-256","speculative":true,"principalName":"unifi","authenticationDatabase":"unifi","remote":"172.19.0.3:50624","extraInfo":{}}} {"t":{"$date":"2024-01-05T15:59:23.293+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"WTCheckpointThread","msg":"WiredTiger message","attr":{"message":"[1704470363:293326][1:0x15273f73d700], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 6840, snapshot max: 6840 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 660"}} {"t":{"$date":"2024-01-05T16:00:23.344+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"WTCheckpointThread","msg":"WiredTiger message","attr":{"message":"[1704470423:344527][1:0x15273f73d700], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 6918, snapshot max: 6918 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 660"}} {"t":{"$date":"2024-01-05T16:01:23.377+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"WTCheckpointThread","msg":"WiredTiger message","attr":{"message":"[1704470483:377873][1:0x15273f73d700], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 6921, snapshot max: 6921 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 660"}} {"t":{"$date":"2024-01-05T16:02:23.398+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"WTCheckpointThread","msg":"WiredTiger message","attr":{"message":"[1704470543:398781][1:0x15273f73d700], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 6969, snapshot max: 6969 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 660"}} {"t":{"$date":"2024-01-05T16:03:23.425+00:00"},"s":"I", "c":"STORAGE", "id":22430, "ctx":"WTCheckpointThread","msg":"WiredTiger message","attr":{"message":"[1704470603:425199][1:0x15273f73d700], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 6974, snapshot max: 6974 snapshot count: 0, oldest timestamp: (0, 0) , meta checkpoint timestamp: (0, 0) base write gen: 660"}} Is anyone else running the Mongo container getting this? Any idea what it means? Is the log by default set to verbose? This will eat up space really quickly.

I've been putting off the switch to the new Docker, but was wondering: is it worth moving to v8 before I make the switch, or after? Or is it still too early to trust Ubiquiti with a new major version, and I should just stick with v7 for a while longer, anyway? Thanks for your insight!

While there's a fix for a data corruption issue in ZFS, is there any way we can find out if we were affected by the corruption?

Ok, I've changed the command to: rsync -av --times --delete --exclude '.Recycle.Bin' /mnt/disk1/mymusic $MOUNTPOINT 2>&1 >> $LOGFILE And the log is filled with e.g. rsync: [generator] chown "/mnt/disks/ADATA2TB/mymusic/Albums/Conjoint/[2000] Earprints [FLAC]/01. Earprint Nr1.flac" failed: Operation not permitted (1) For every file and dir (I think because exfat doesn't support permissions etc, and the -a flag is the equivalent of -rlptgoD, which includes groups, permissions etc). The rsync man page says, however, suggests that --size-only could be a useful flag here as: "This modifies rsync's lqquick checkrq algorithm for finding files that need to be transferred, changing it from the default of transferring files with either a changed size or a changed last-modified time to just looking for files that have changed in size. This is useful when starting to use rsync after using another mirroring system which may not preserve timestamps exactly." So I've changed my rsync command to: rsync -vrltD --size-only --delete --exclude '.Recycle.Bin' /mnt/disk1/mymusic $MOUNTPOINT 2>&1 >> $LOGFILE And it worked for a run (no changes to sync, however). I will find out when daylight savings next changes if this solution has worked (though I suspect it will). I'll report back if changing to 'size only' causes any weird sync issues. Thanks for your help.

Ah, I already specified -t in my command (vrltD --delete), so I don't think it'll fix it. The issue is that the server's time changes for DST, but the timezone for the exfat isn't specified, so it thinks that every file has shifted by an hour. If it isn't possible to specify the TZ for a specific disk in UD, I'll keep hunting around for an rsync solution. A workaround is to specify "--modify-window=3601", though this means that if I modify something, sync it, then modify it again all within an hour, it won't sync those changes next time. I can probably keep this in mind, though. Thanks.

Oh, I didn't realise that would work on exfat. Many thanks!

Hi, sorry, I originally quoted an earlier detailed post, which can be found here: The summary is that I have an exfat disk that I keep music on and which is accessed by Windows and Mac computers (thus my preference for exfat). I sync it from my server using UD and rsync (the rsync script is in the original post). I posted a while ago that it occasionally syncs the entire drive contents, rather than just what has changed, and I now realise it's because of daylight savings changing, and exfat not using unix time. At the time I thought maybe the drive was failing. One solution is to mount the device using the option "tz-utc", so that the time stamps don't change when the UK moves over to DST (we're effectively on UTC otherwise), so I was wondering if it was possible to mount specific disks as UTC, and how to do it. I would think that the script would be too late for adding that mounting option, correct? I'm open to other suggestions, though, including modifying the rsync command/script, or even moving to a format freely and reliably supported by Windows and Mac that also supports unix timestamps/DST. The rsync command from the script is: rsync -vrltD --delete --exclude '.Recycle.Bin' /mnt/user/mymusic $MOUNTPOINT 2>&1 >> $LOGFILE Many thanks.

Does anyone know how to mount disks with the tz=UTC option?

So, the same thing happened again today: I plugged in my 'sporadic' backup disk and it started copying everything again. I went back to find my old post to see what the solution was, and I couldn't help but notice that I mentioned in my original post that this happened the first time plugging in the disk since daylight savings time started. Well, this is actually the first time I've plugged in the disk since daylight savings time ended and here we are with it copying over everything again. I note that it doesn't happen with my other backup disk, which is formatted in ext4. Could this be related to the disk being exfat and the file timestamps changing relative to DST? Is the solution to run my server as UTC, or is the solution to modify my script? If it's running the server in UTC, what are the drawbacks? I'm assuming I can still choose timezones in Docker apps, yes (my Squeezeboxes are also my clocks)? Thanks for your help and input. EDIT: I note that this page: https://askubuntu.com/questions/1323668/one-volume-did-not-go-dst-with-the-rest-of-the-system Mentions that you can mount disks using the option: tz=UTC How would I go about adding that option to UD for this disk?

I know I'm digging up an old thread here, but I thought I'd chime in with something I found out yesterday: For some reason, my LSIO NextCloud instance had the log level defined in config.php set at 0 (debug), rather than the default 2 (warn). I'd never set this myself, so I'm assuming it's a silly default set by LSIO. Since I changed it, my instance seems snappier and my photo thumbnails in this third party Android app (https://play.google.com/store/apps/details?id=com.nkming.nc_photos.paid) load heaps quicker as I jump through the timeline. So, if anyone on the LSIO NextCloud container is experiencing problems, double check the log level set in your config.php HTH

I installed it anyway and am now running "2023.09.05.31.main" Is it suitable for public consumption?

Sorry, I don't know what that error means. LS.io no longer offer support through this forum, instead offering it through their Discord, so maybe try there.

Dunno quite what that means. Some use Bridge, some use Host, some use a custom network for reverse proxy (Swag + Nextcloud).

Just adding to the voices on this issue: I use MACVLAN on Docker, and have had no problems with that. I have Unifi gear (USG and 2x APs, with the controller running in Docker), and have no problems (except for it complaining that my bonded eth on the server shares an IP address). If there's anything I can do to help troubleshoot this problem (contributing to a known-working hardware list, for instance), feel free to reach out.

FWIW, I copied all the .err files to a new directory (just in case), I then deleted all of them except the one listed in the logs at start-up. I then renamed the active log file to <filename>.err.old I then logged into the mysql console by opening the mariadb console via the Unraid GUI, then issuing the command: mysql -uroot -p As per https://mariadb.com/kb/en/flush/, I then issued the command to close and reopen the .err file (basically recreate it) flush error logs; Now the .err file is KB in size, and I have recovered 3GB of space on the cache drive by clearing the errors that have been accumulating for a couple years now. Fingers crossed I haven't messed anything up!

I Googled the error this morning and it seems to be a problem from a poor upgrade between mariadb versions (ie the container updated the version, but there were manual steps needed inside the container that I was not aware of). This thread shed some light on it: https://github.com/photoprism/photoprism/issues/2382 Specifically, I ran the following command, and now the error isn't constantly spamming the .err logfiles. mysql_upgrade --user=root --password=<root_pwd> Does anyone know if I can just delete all the .err files from the folder now?

Hi there, I remember after this image was rebased to Apline that my start up log (the one accessed when clicking on the mariadb icon in the Unraid Docker UI) started producing the following each time it started: [custom-init] No custom files found, skipping... 230720 11:04:18 mysqld_safe Logging to '/config/databases/98d77ae0f2c7.err'. 230720 11:04:18 mysqld_safe Starting mariadbd daemon with databases from /config/databases [ls.io-init] done Everything seemed to work correctly, so I didn't really think much about that mention of a .err file. Fast forward a couple years (maybe?), and I just realised that my mariadb appdata directory is about 4GB in size, while my db backups are only about 80MB. I was worried that the backups weren't running correctly, so started digging around in the 'db-backup' Docker that I use to back it up. I couldn't find anything in the logs. Long story short, I have just under 4GB of .err files in the mariadb appdata directory. Opening up the .err file that is referenced in the above log, I see that it's constantly filling with: 2023-07-20 13:43:56 362 [ERROR] Incorrect definition of table mysql.column_stats: expected column 'hist_type' at position 9 to have type enum('SINGLE_PREC_HB','DOUBLE_PREC_HB','JSON_HB'), found type enum('SINGLE_PREC_HB','DOUBLE_PREC_HB'). 2023-07-20 13:43:56 362 [ERROR] Incorrect definition of table mysql.column_stats: expected column 'histogram' at position 10 to have type longblob, found type varbinary(255). Over and over and over again. How do I fix this? The only app I use mariadb for is Nextcloud, which I also use the LSIO Docker for. Thanks for your help.

Thanks, I shall then. Is the reason that they weren't automatically created as datasets because I used MC (disk share to disk share) to move the shares to the Pool, instead of the Mover? (just so that I don't make a similar mistake again)

Hi there. I've been excited to move to ZFS for the snapshotting capabilities, so I've been following Spaceinvader One's videos and have converted my cache pool (2x 250GB SSD), my Nextcloud share (2x 2TB SSD), as well as my "Backup" disk in the array (2TB HDD) to ZFS. I've installed the ZFS Master plugin, and was hoping to start creating snapshots as my main backup, and then using "ZFS send" to back them up to the ZFS disk in the array (replacing my current rsync script). However, I note in the ZFS Master plugin that, while my cache drive and Backup drive both have all of their top level shares as datasets, the 2TB SSD pool only contains folders. Why is this? (see below for the methodology I used to convert the pool) And what's the best way to convert the folders into datasets? Should I use the Mover to copy the contents of each share in the pool to the array, then back again? (will this automatically make the shares in the pool datasets?) Diagnostics attached, if they're required. More detail on how the 2TB pool was created: The "pool" was originally a single BTRFS SSD (called 'ssd2tb') that contained 3x shares: one for my Nextcloud data; one for my photos; and another one specifically for the photos I want streamed to a digital photo frame I have. I bought a second 2TB SSD and formatted it as ZFS, naming it 'pool2tb'. I then used Midnight Commander to copy the contents of ssd2tb to pool2tb Once done, I erased ssd2tb, deleted the ssd2tb pool, formatted it as zfs, and added that ssd as a mirrored disk in 'pool2tb' Does any of that explain why the 3x shares on pool2tb are folders, not datasets? (while the shares on my 'cache' zfs pool are datasets?) And what do I have to do to convert them to datasets? Many thanks for your help. percy-diagnostics-20230718-1428.zip

Amazing, well done JorgeB! Thanks for all your help over the years!

Just a guess: are there any port conflicts with other Dockers?