ich777

Can you try to disable the avahi services, to do that simply execute this two commands from the terminal and see if it fixes the issue: /etc/rc.d/rc.avahidaemon stop /etc/rc.d/rc.avahidnsconfd stop Do you have Docker containers in br0 mode?

Do you have no monitor or dummy plug connected by default? This could also be the issue. I know many people using such CPUs and having no issue whatsoever using HW transcoding.

Please keep in mind that if you use raync it would be completely the same. Have you yet tried to split your sync into smaller syncs so to speak maybe try to create one sync per share.

Yes, this is of course possible. Yes, but you have to maybe switch slots because you are forced to use the card which outputs the BIOS screen/console output from Unraid on boot. You also have to maybe change a line in the config (if you only got a blinking cursor in GUI mode) but this is something for later.

Have you yet read the last 30 comments here in the thread because this is now solved for most people.

Yes. The description also mentions that. Behind the scenes. This is the default behaviour because luckyBackup is designed to be a Desktop application and the schedules are only working when you use the console mode.

This was just a guess, I really don't know what the cause of this issue was because I don't know what you are backing up. It is never a good idea to sync everything blindly because you are most certainly backing up files that aren't necessary, anyways, let it run and report back when it's finished creating the file list.

But the file list generation shouldn't take that long, how much files are you backing up? Even my Nextcloud folder (which is currently huge with a lot of pictures and so on) won't take much longer than about 20minutes to generate the file list. But then one night without shutting down the server should do the job just fine so that everything finishes or am I wrong? I think that you don't have to let it run over night for when this huge sync is finished correct?

I don't think so because rsync isn't made for that since the files could change on the source and that would be pretty bad. May I ask how often do you sync? 2TB can't take more then a day usually and it should shut off fine in the evening or at least split your syncs into separate folders and run them on a schedule. Even DirSyncPro can't do that...

You have to install that in the container.

On @Spectral Force‘s Discord I think. Mod installation is the same as on bare metal with slightly different paths if you have to specify them.

luckyBackup uses rsync as backend, ao to speak it is more of a fance frontend for rsync. Is it possible that you have many many many small files in those 2TB? Usually this is an indication that the container crashed because it ran out of RAM. You can but it would be basically be the same if you got lots of files to sync and from my experience DirSyncPro can use a lot of RAM when you have lots of small files. You can however create smaller sync chunks in luckyBackup on a per folder basis to circumvent this. I‘m using luckyBackup to sync my whole server and had no issues so far.

No thank you… Sure thing, I also know that but the redistribution from the drivers is not allowed AFAIK and that‘s why I have not created a plugin for that (and I really don‘t want that they take down my GitHub). So sharing the scripts here on the forums or even in a GitRepo of yours should be fine.

Sounds a bit complicated but can you do the following: Uninstall the Plugin Reboot Install the Plugin again Reboot once more or restart the Docker service I‘ve now tried it again on another machine and 6.11.5 and it is working there too as it should. I will contact another user if he can test that for me too.

This is not strictly speaking a error this is more a warning., the last lines mean that the server is up and running. Have you yet tried to connect to the server with your <localip>:<queryport> Did you yet tried to add the server to your Steam Server Browser (in Steam -> View -> Servers -> Favorites -> Add Server)?

I don't think that if you post the scripts to build the non public drivers anyone can come after you as long as you post how to legally obtain a license and the vgpu binaries which are needed to do so. Sorry, I really can't help here because I simply don't have a card that has the capabilities to make use of a vGPU and I even don't know how this is all working.

I can't reproduce this on my end, I've even tried to downgrade to the driver version 470.141.03 and then set it again to latest and it properly downloaded the latest (v530.30.02) driver version.

Sadly enough no, this is a well known issue... The answer is also no... I don't think so, make at least sure that you use a HDMI Dummy Plug on the physical iGPU to prevent the messages in your syslog and to improve stability.

Are you sure that nothing is using up the assigned VRAM for GVT-g in the VM? Usually crashes like you describe it if the assigned VRAM is exceeded. Do you have a physical monitor connected to the iGPU, if not connect at least something like a HDMI Dummy Plug to the on board HDMI port to avoid this issue.

Then the crash is most certainly not related to the Nvidia Driver. Have you yet changed MACVLAN to IPVLAN in your Docker settings? MACVLAN is notorious to crash servers with similar Kernel panics. May I ask why? The open source module has no real benefit...

Sorry for the delayed answer... I've pushed a update to the plugin where you now can select the driver version 470.xx Please update the plugin and see if it fixes the issue for you.

Is there a possibility to show the key too instead of only generating the QR code and the URL for Bitwarden,...? I'm using Enpass and I need the key instead of the URL, of course I could copy the URL, paste the URL somewhere and extract only the key but this seems tedious for users who are running into the same situation...

Is this the official container? You are missing as mentioned in the second post of this thread: NVIDIA_DRIVER_CAPABILITIES=all Both of your GPUs are recognized and ready to transcode: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU102 [GeForce RTX 2080 Ti Rev. A] [10de:1e07] (rev a1) Subsystem: eVga.com. Corp. TU102 [GeForce RTX 2080 Ti Rev. A] [3842:2484] Kernel driver in use: nvidia Kernel modules: nvidia_drm, nvidia 01:00.1 Audio device [0403]: NVIDIA Corporation TU102 High Definition Audio Controller [10de:10f7] (rev a1) Subsystem: eVga.com. Corp. TU102 High Definition Audio Controller [3842:2484] 01:00.2 USB controller [0c03]: NVIDIA Corporation TU102 USB 3.1 Host Controller [10de:1ad6] (rev a1) Subsystem: eVga.com. Corp. TU102 USB 3.1 Host Controller [3842:2484] Kernel driver in use: xhci_hcd 01:00.3 Serial bus controller [0c80]: NVIDIA Corporation TU102 USB Type-C UCSI Controller [10de:1ad7] (rev a1) Subsystem: eVga.com. Corp. TU102 USB Type-C UCSI Controller [3842:2484] 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU102 [GeForce RTX 2080 Ti Rev. A] [10de:1e07] (rev a1) Subsystem: eVga.com. Corp. TU102 [GeForce RTX 2080 Ti Rev. A] [3842:2489] Kernel driver in use: nvidia Kernel modules: nvidia_drm, nvidia 02:00.1 Audio device [0403]: NVIDIA Corporation TU102 High Definition Audio Controller [10de:10f7] (rev a1) Subsystem: eVga.com. Corp. TU102 High Definition Audio Controller [3842:2489] 02:00.2 USB controller [0c03]: NVIDIA Corporation TU102 USB 3.1 Host Controller [10de:1ad6] (rev a1) Subsystem: eVga.com. Corp. TU102 USB 3.1 Host Controller [3842:2489] Kernel driver in use: xhci_hcd 02:00.3 Serial bus controller [0c80]: NVIDIA Corporation TU102 USB Type-C UCSI Controller [10de:1ad7] (rev a1) Subsystem: eVga.com. Corp. TU102 USB Type-C UCSI Controller [3842:2489] It seems to me that there is something wrong with the configuration from the container itself. As mentioned above, please try to official Plex container if you are not already using it and add the variable.

Please post your Diagnostics. Without them I can‘t say anything.

Give me a bit, I‘m currently not at home, will try that when I got home and report back.