ich777

Sorry, I maybe wasn't clear enough. You wont see anything in the container log, after a cronjob is finished you have to restart the container and then you have to open the logs in the WebUI from luckyBackup and there you will see the log from the executed cron job but as said only after a restart from the container.

Please create a post in the General subforums, this is not related to a plugin this is directly related to the base OS.

Shouldn‘t be needed anymore since this was implemented upstrem into the Kernel.

This just means that it creates a extra directory in the sync directory which is named after the task. Do you have this option enabled or disabled: How did you do that? Is that probably related to the exclusion of the files? However I would recommend that you just create a sync for each share with that you have more granular control what data you want to sync. This always depends on how it's configured but without any screenshots/further information it is really hard to say why this all is happening. Please always keep in mind that luckyBackup is just a GUI for rsync in the background it runs simple plain rsync if you want you even can show the rsync command by clicking Validate in the various share settings. From another post I saw you have issues deleting a dataset, so I assume you are using ZFS correct? Sorry, can't help with that, that's why I created this container, maybe someone else has another idea.

I've edited the post, however your explanation is lacking why, but anyways this means from my side no plugins from EDACerton on my server. :) Thanks for the explanation.

But what and why are you even collecting? As far as I can see you are hashing the flashGUID, the plugin name, the plugin version and the Unraid version. I really don't know why you would do that and even more ...daily? I assume you know that you can also ask the GitHub API how much downloads are on the Releases.

I really don't know where you've get that from but @Mainfrezzer already posted what to do: so to speak: Please note that you also have to set VALIDATE to true when you switch branches.

Please keep in mind that 5000 series cards are known to have issues with PCIe 5.0 and it is recommended for users with issues to even switch to PCIe 4.0 This is not related to Unraid, this is hardware related and this is something that your Motherboard Manufacturer with a BIOS update or even Nvidia has to solve.

This is just normal since luckyBackup is just a frontend for rsync and it was never designed for a Docker container, however the logs should fill when you restart the container after a cron job was executed, this is a known issue. Another question, do you have CA Backup installed if yes, please keep in mind that by default the containers are stopped to create a backup and if that time overlaps with your backup schedule that might cause the issue. I assume the container is running when you have set to execute the schedule correct?

I assume you are talking about luckyBackup correct? Please provide more information on that, did you made sure to enable console mode when clicking Cron IT?

@Spectral Force can you please help here.

Yes looking good, from what I see you switched slots from the GPUs and enabled UEFI boot. Glad to hear that everything is working now.

You have multiple issues: May 21 10:03:26 server kernel: nvidia 0000:0b:00.0: enabling device (0000 -> 0003) May 21 10:03:26 server kernel: NVRM: This PCI I/O region assigned to your NVIDIA device is invalid: May 21 10:03:26 server kernel: NVRM: BAR1 is 0M @ 0x0 (PCI:0000:0b:00.0) May 21 10:03:26 server kernel: NVRM: This PCI I/O region assigned to your NVIDIA device is invalid: May 21 10:03:26 server kernel: NVRM: BAR2 is 0M @ 0x0 (PCI:0000:0b:00.0) May 21 10:03:26 server kernel: NVRM: This PCI I/O region assigned to your NVIDIA device is invalid: May 21 10:03:26 server kernel: NVRM: BAR3 is 0M @ 0x0 (PCI:0000:0b:00.0) May 21 10:03:26 server kernel: NVRM: This PCI I/O region assigned to your NVIDIA device is invalid: May 21 10:03:26 server kernel: NVRM: BAR4 is 0M @ 0x0 (PCI:0000:0b:00.0)and: May 21 10:04:20 server kernel: NVRM: GPU 0000:0b:00.0: RmInitAdapter failed! (0x24:0x72:1512) May 21 10:04:20 server kernel: NVRM: GPU 0000:0b:00.0: rm_init_adapter failed, device minor number 0 May 21 10:04:20 server kernel: nvidia_uvm: module uses symbols nvUvmInterfaceDisableAccessCntr from proprietary module nvidia, inheriting taint. May 21 10:04:20 server kernel: pci 0000:06:00.0: VPD access failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update May 21 10:04:21 server kernel: resource: resource sanity check: requesting [mem 0x00000000de700000-0x00000000df6fffff], which spans more than 0000:0b:00.0 [mem 0xde000000-0xdeffffff] May 21 10:04:21 server kernel: caller _nv046997rm+0x3a/0xb0 [nvidia] mapping multiple BARs May 21 10:04:21 server kernel: NVRM: GPU 0000:0b:00.0: RmInitAdapter failed! (0x24:0x72:1512) May 21 10:04:21 server kernel: NVRM: GPU 0000:0b:00.0: rm_init_adapter failed, device minor number 0 May 21 10:04:21 server emhttpd: error: get_key_info, 683: Invalid argument (22): stat: /boot/config/Plus.key May 21 10:04:21 server kernel: resource: resource sanity check: requesting [mem 0x00000000de700000-0x00000000df6fffff], which spans more than 0000:0b:00.0 [mem 0xde000000-0xdeffffff] May 21 10:04:21 server kernel: caller _nv046997rm+0x3a/0xb0 [nvidia] mapping multiple BARs May 21 10:04:21 server kernel: NVRM: GPU 0000:0b:00.0: RmInitAdapter failed! (0x24:0x72:1512) May 21 10:04:21 server kernel: NVRM: GPU 0000:0b:00.0: rm_init_adapter failed, device minor number 0I see that you also booting with Legacy, can you please enable UEFI boot mode and also set UEFI boot in your BIOS and see if that solves the issue? Are you really sure that you've enabled Resizable BAR support, usually you have to boot into UEFI mode to fully support that.

Sadly enough no, my time is really limited right now. ...it's still on my TODO list.

You've enabled the nouveau driver by creating the file /boot/config/modprobe.d/nouveau.conf: May 20 17:34:58 JeffmiaoUnraid kernel: NVRM: GPU 0000:b3:00.0 is already bound to nouveau. May 20 17:34:58 JeffmiaoUnraid kernel: NVRM: The NVIDIA probe routine was not called for 1 device(s). May 20 17:34:58 JeffmiaoUnraid kernel: NVRM: This can occur when another driver was loaded and May 20 17:34:58 JeffmiaoUnraid kernel: NVRM: obtained ownership of the NVIDIA device(s). May 20 17:34:58 JeffmiaoUnraid kernel: NVRM: Try unloading the conflicting kernel module (and/or May 20 17:34:58 JeffmiaoUnraid kernel: NVRM: reconfigure your kernel without the conflicting May 20 17:34:58 JeffmiaoUnraid kernel: NVRM: driver(s)), then try loading the NVIDIA kernel module May 20 17:34:58 JeffmiaoUnraid kernel: NVRM: again. May 20 17:34:58 JeffmiaoUnraid kernel: NVRM: No NVIDIA devices probed. If you want to revert that and use the Nvidia Driver plugin you have to issue this command from an Unraid Terminal: rm -f /boot/config/modprobe.d/nouveau.conf and reboot afterwards.

Please always include your Diagnostics.

Please create a post in the General sub forums, I think your USB flash drive dropped offline and that's why you can't issue the command: At least something seems wrong to me, please try to reboot your server and issue the command right after the reboot.

Can you try to open up a terminal from Unraid and issue: diagnostics after that you will find the Diagnostics in /boot/logs

Please post your Diagnostics as pointed out above. This indicates a general issue with the server... How much RAM do you have installed? What USB Boot device are you using? Are you sure you have enough free space on it?

Do you have Diagnostics? How long did you wait until you got the error? It seems that you installed the plugin already once, please remove the plugin (go to the Plugins page and make sure it's not listed there anymore) reboot and try to reinstall it and wait for the dialogue to display the DONE button.

It could be possible, but first I would recommend that you try to set the PCIe generation to gen4 instead of 5. Such adapters can always cause trouble but they don't have to as long as the signal integrity is okay, however that is nearly impossible to test without proper equipment. I would not recommend to use risers at all since this is always some kind of hit and miss, in addition to that it was reported that 5000 series cards often times have issues with Motherboards and PCIe gen5. Update your BIOS, then set the link speed to gen4 and then see if it's working, if you get the same error then it's probably the riser, it's always a bit of hit and miss with risers.

You can still leave it at x16 but I recommend trying PCIe gen4 or even gen3, as said above, that won't matter much if you are using it only for transcoding, for LLMs it's kind of a different story.

Yes: May 19 15:37:42 RossiServer kernel: NVRM: GPU at PCI:0000:02:00: GPU-b929ec99-7a23-84fc-6748-5ce8e5230fb7 May 19 15:37:42 RossiServer kernel: NVRM: Xid (PCI:0000:02:00): 79, GPU has fallen off the bus. May 19 15:37:42 RossiServer kernel: NVRM: GPU 0000:02:00.0: GPU has fallen off the bus. May 19 15:37:42 RossiServer kernel: NVRM: kgspRcAndNotifyAllChannels_IMPL: RC all channels for critical error 79. May 19 15:37:42 RossiServer kernel: NVRM: _issueRpcAndWait: rpcSendMessage failed with status 0x0000000f for fn 78! May 19 15:37:42 RossiServer kernel: NVRM: nvCheckOkFailedNoLog: Check failed: GPU lost from the bus [NV_ERR_GPU_IS_LOST] (0x0000000F) returned from nvdEngineDumpCallbackHelper(pGpu, pPrbEnc, pNvDumpState, pEngineCallback) @ nv_debug_dump.c:274 May 19 15:37:42 RossiServer kernel: NVRM: RmLogGpuCrash: RmLogGpuCrash: failed to save GPU crash data May 19 15:37:42 RossiServer kernel: NVRM: nvAssertFailedNoLog: Assertion failed: expectedFunc == pHistoryEntry->function @ kernel_gsp.c:2005 May 19 15:37:42 RossiServer kernel: NVRM: _kgspLogRpcSanityCheckFailure: GPU0 sanity check failed 0xf waiting for RPC response from GSP. Expected function 4097 (GSP_INIT_DONE) (0x0 0x0). May 19 15:37:42 RossiServer kernel: NVRM: GPU0 GSP RPC buffer contains function 78 (DUMP_PROTOBUF_COMPONENT) and data 0x0000000000000000 0x0000000000000000. May 19 15:37:42 RossiServer kernel: NVRM: GPU0 RPC history (CPU -> GSP): May 19 15:37:42 RossiServer kernel: NVRM: entry function data0 data1 ts_start ts_end duration actively_polling May 19 15:37:42 RossiServer kernel: NVRM: 0 73 SET_REGISTRY 0x0000000000000000 0x0000000000000000 0x0006357687d77036 0x0000000000000000 y May 19 15:37:42 RossiServer kernel: NVRM: -1 72 GSP_SET_SYSTEM_INFO 0x0000000000000000 0x0000000000000000 0x0006357687d77033 0x0000000000000000 May 19 15:37:42 RossiServer kernel: NVRM: GPU0 RPC event history (CPU <- GSP): May 19 15:37:42 RossiServer kernel: NVRM: entry function data0 data1 ts_start ts_end duration during_incomplete_rpc May 19 15:37:42 RossiServer kernel: NVRM: 0 4124 GSP_LOCKDOWN_NOTICE 0x0000000000000000 0x0000000000000000 0x0006357687e55811 0x0006357687e55811 y May 19 15:37:42 RossiServer kernel: NVRM: -1 4124 GSP_LOCKDOWN_NOTICE 0x0000000000000001 0x0000000000000000 0x0006357687e5478a 0x0006357687e5478a y May 19 15:37:42 RossiServer kernel: NVRM: -2 4124 GSP_LOCKDOWN_NOTICE 0x0000000000000000 0x0000000000000000 0x0006357687e54691 0x0006357687e54691 y May 19 15:37:42 RossiServer kernel: NVRM: -3 4124 GSP_LOCKDOWN_NOTICE 0x0000000000000001 0x0000000000000000 0x0006357687e54367 0x0006357687e54367 y May 19 15:37:42 RossiServer kernel: NVRM: -4 4124 GSP_LOCKDOWN_NOTICE 0x0000000000000000 0x0000000000000000 0x0006357687e40b54 0x0006357687e40b54 y May 19 15:37:42 RossiServer kernel: NVRM: -5 4124 GSP_LOCKDOWN_NOTICE 0x0000000000000001 0x0000000000000000 0x0006357687e40ad5 0x0006357687e40ad5 y May 19 15:37:42 RossiServer kernel: NVRM: -6 4128 GSP_POST_NOCAT_RECORD 0x0000000000000002 0x0000000000000027 0x0006357687e406c9 0x0006357687e406ca 1us y May 19 15:37:42 RossiServer kernel: NVRM: -7 4124 GSP_LOCKDOWN_NOTICE 0x0000000000000000 0x0000000000000000 0x0006357687e3f9ff 0x0006357687e3f9ff y At least similar, you have the XID error 79 which indicates a Bus error, maybe try to set the link gen for this specific PCIe interface to Gen4 or even Gen3 <- won't matter much if you are using the card only for transcoding, you can get more information about XID errors here and what they mean. However I don't recommend using a riser at all because timing needs to be very precise and only a minimal interference can cause such an issue.

Nope… Maybe look out for a second card that you can use for transcoding, something like a Nvidia T400 will do the job just fine. However I just saw that you have a 12400F maybe try to get a 12400 (without F) because these chip have a iGPU and these are capable of transcoding neraly everything and will exceed what you can currently transcode with your GTX960, so to speak use the iGPU for transcoding and your dGPU for the VM.

Your card is bound to VFIO as you can see from your syslog: May 18 14:36:34 nebanas kernel: NVRM: GPU 0000:01:00.0 is already bound to vfio-pci. May 18 14:36:34 nebanas kernel: NVRM: The NVIDIA probe routine was not called for 1 device(s). May 18 14:36:34 nebanas kernel: NVRM: This can occur when another driver was loaded and May 18 14:36:34 nebanas kernel: NVRM: obtained ownership of the NVIDIA device(s). May 18 14:36:34 nebanas kernel: NVRM: Try unloading the conflicting kernel module (and/or May 18 14:36:34 nebanas kernel: NVRM: reconfigure your kernel without the conflicting May 18 14:36:34 nebanas kernel: NVRM: driver(s)), then try loading the NVIDIA kernel module May 18 14:36:34 nebanas kernel: NVRM: again. May 18 14:36:34 nebanas kernel: NVRM: No NVIDIA devices probed. and also here in your PCI devices: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM206 [GeForce GTX 960] [10de:1401] (rev a1) Subsystem: ASUSTeK Computer Inc. Device [1043:854d] Kernel driver in use: vfio-pci Kernel modules: nouveau, nvidia_drm, nvidia 01:00.1 Audio device [0403]: NVIDIA Corporation GM206 High Definition Audio Controller [10de:0fba] (rev a1) Subsystem: ASUSTeK Computer Inc. Device [1043:854d] Kernel driver in use: vfio-pci Please unbind the card from VFIO and reboot, after that the card should work as usual. And please remove that script, that isn't working anymore with the newer drivers: May 18 14:37:29 nebanas emhttpd: /usr/local/emhttp/plugins/user.scripts/backgroundScript.sh "/tmp/user.scripts/tmpScripts/Unlock Nvidia/script" >/dev/null 2>&1/usr/local/emhttp/plugins/user.scripts/backgroundScript.sh "/tmp/user.scripts/tmpScripts/01 Nvidia Powersafe/script" >/dev/null 2>&1