ken-ji

Looks like a bug with the shfs used by Unraid.

Sadly I don't have any. Probably should document it for my own peace of mind.

You can probably check your router to see which port does these mac address appear. Also have you tried shutting down everything (VMs, containers) on your Unraid to see if the issue occurs? It seems like you'll need to really check your network to see where the craziness is coming from.

This sounds like you have a docker container running in bridge mode and its somehow announcing itself on the LAN with the incorrect internal IP But I don't remember seeing anything like that in your diagnostics file

so I took a look at the ipmi plugin and plugin package it installs is badly built. Granted when the package is installed and doesn't have a derekmacias user or group, they will fallback to the numeric value which happens to be 1000 hence admin:1000 for @elkaboing. This will break SSH access and maybe a few other such things. The plugin author @dmacias probably doesn't use ssh (and neither do the other IPMI users, hence they haven't seen this issue)

How are you pinging? vi hostname?

In my experience, this means you probably have a plugin that installed files owned by the user id 1000 (this is assigned to the first user created in any Unraid/Linux system) and group id 1000 So when you have a chance to reboot, try so to make sure its not an accidental chown. And if it did comeback, you'll have to inspect each of your plugins to determine if any is incorrectly built.

You actually want to be using private keys and the builtin background capability of SSH I'll assume you known how to generate private+public key pairs else see this for a primer When you are sure the keys are working correctly (generate them without passphrase encryption) and can ssh to the other server without being prompted for anything, Try the ssh command below (which will be exact command you stick into your script or go file) #!/bin/bash ssh -f -i path/to/ssh/private.key -R 8000:xxx.xxx.xxx.xxx:8000 [email protected]

Here's what I did in my own system (also behind CGNAT). Spun up a Mikrotik CHR (virtual router) on Linode (but any other VPS with completely unblocked ports is also fine). Made a site-to-site VPN between my home networks (3 different houses) and the VPS. then port forwarded port 80 + 443 to an nginx container (kinda like SWAG - but I prefer to roll my own). This could be done with a Linux VPS, but I wanted to play with a Mikrotik router (all of my edge routers are Mikrotiks) and have less issues with the rather performant IPSec site-to-site vpn This means I can access my Emby server + Transmission container over HTTPS from anywhere. (Added DNS entries at the house with the Unraid server to avoid having to go out and back)

I have rclone plugin installed and run this using the User Scripts plugin #!/bin/bash #argumentDescription=Backup Location #argumentDefault=/mnt/disks/VMs/appdata/backupFlash BACKUPDIR=$1 [ -z ${BACKUPDIR} ] && BACKUPDIR=/mnt/disks/VMs/appdata/backupFlash mkdir -p ${BACKUPDIR} tar -C /boot -zvcf ${BACKUPDIR}/`hostname`-flash-`date +%Y%m%d%H%M%S`.tgz --exclude config/super.dat --exclude 'previous*' --exclude 'bz*' --exclude "System Volume Information" . #cleanup - leave upto 14days worth of backups find ${BACKUPDIR} -ctime +14 -delete if [ -x /usr/local/bin/rclone ]; then # rclone sync ${BACKUPDIR} Drive:backupFlash --verbose rclone sync ${BACKUPDIR} OneDrive:backupFlash --verbose rclone sync ${BACKUPDIR} Dropbox:backupFlash --verbose fi The script will tar + compress the entire USB flash drive into a timestamped file - skipping config/super.dat (since my array drive order are absolute and easy to rebuild) and the bz* files and store in an unassigned drive location and finally upload to One Drive and Dropbox

Your going to have to provide examples/screenshots and probably logs regarding this bug report as anybody trying to replicate this would just ignore it as there's nothing in here to follow

Self-signed certs are the CA themselves... unless you are using self-CA signed ones? and I think the browsers will now warn on self-signed certs - even if they were trusted?

Haven't done this myself - but is there any reason why importing the OVA into LibVirt/KVM/QEMU not working for you?

This is exactly how networking works. When any process decides to access something, the network stack consults the routing table and determines what interface and router to use. If your untagged interface (regardless of IP) does not have a gateway defined then it will not get used to reach the internet. A lot of times before people had multiple VLANs with gateways configured (statically or dhcp), this would make it so the lastest interface to come up and be added to routing table would get used as the internet connection - even if the last interface to come up doesn't have a working internet. I suppose a missing feature of unraid is the ability for us to define/tweak the desired table, including overrides for DHCP enabled interfaces and other suck configurations.

@theruck for #1, by default the Dropbox data is shared over SMB. the defaults assume you are using Unraid in the default public share mode If this is not the case (you are using user accounts, set User and User ID to the appropriate user) refer to this for more details For #2. Just set the autostart button to on on the Dockers page

I'm afraid I have no idea what's going on here. and as you can see from your logs, it contains nothing useful. Only the Dropbox devs probably know what's going on and I don't think they are going to be helpful at all . This headless client is something they are still supporting but they seem to be veering people away from it as its not too easy to find on the site anymore.

Correct This whole stopping to sync is something I haven't encountered and I have no Idea what's causing it. I only have 3.5G in my Dropbox account and I've never seen it stop syncing. Losing the linked account data yes, but never the hanging on the sync.

@jang430 If you haven't figured it out, your go file is wrong it should be #!/bin/bash modprobe i915 chmod -R 0777 /dev/dri # this must be the last thing in the go file unless you really know why # Start the Management Utility /usr/local/sbin/emhttp &

Because Dropbox is meant to be run and used by a single user, the container must create files as a single user and any access over Samba/NFS shares must result in the files being owned by the same user or some issues will occur (like being unable to update directories and files modified from other devices) There is a setting you can apply (just not sure how it will mess things up further for you) in Settings | Samba | SMB extras I added under the [global] section force user = nobody force group = users this makes it so that all access to my files over Samba will be done as the nobody user (and the group users - but this is usually not important). Enabling this will probably break any existing share that is Secure, Private or even Public ones - if the files and directories have been created with the existing users you may have defined. (Running either Fix Permissions tools on the affected shares should fix the issue though) You can turn this on and make some tests on a existing share so you understand what it does though, as reversing it is fairly easy by just removing the lines. I was suggesting that Unraid enable this out of the box, but there's no way AFAIK to do it and not cause issues with users who do not want to enable this.

This Docker container will run stuff as the nobody user, hence the error message above regarding permissions. Docker Safe New Perms will work until new files get sync'd or updates are made. I'm guessing, but are you accessing the Dropbox share in guest mode (ie its set to Public) while you have a user in Unraid that the Windows PC you have is set to use/match? (Windows Credentials in Settings) If so, you probably want to blow away this container and the appdata/dropbox and Dropbox share/folders (ie really start over) Then when you reinstall the container, before linking to your account, make sure that the user id to run as is set to the user id of your user (the one windows is using to connect to) If you don't know your user id, just open a terminal to Unraid and run this root@MediaStore:~# id username uid=1000(username) gid=100(users) groups=100(users) which is usually be 1000.

It won't bypass the integrity, but i wonder how you plan to run the second instance. As a VM perhaps? or as a docker container with its own IP? I ask this as you can't run a second Samba instance due to conflict with the service ports (only one process can listen on a port)

Try keeping the SSD on the motherboard ports, not the HBA - I don't have the links but I remember there was discussion about TRIM not being supported on most HBAs, only standard AHCI controllers.

Like any forum, one reason you didn't get a response is because there's nobody with anything to contribute or they just missed your post. But in any case about the SSD. just about any SSD should be ok. a possible cause of the slowdown is that your SSD is currently out of free/empty blocks and now the drive has to do a block erase before being able to write anything - causing a massive slowdown. Are you TRIMming the SSD? and is the SSD connected to something other than an HBA? - this is because some HBAs do not support running TRIM. There's the Dynamix TRIM plugin for this. As for the GPU and docker passthrough, you'll need to have the NVIDIA drivers installed via the linuxserver.io plugin or another that lets you rebuild the kernel as you need. In a nutshell, for a docker container to use host hardware, the host needs to be able to use it via host drivers, which is then passed to the container so that container apps can interact with the device. I believe there's more on the specific thread for Plex container you have installed.

Yes, forcing it to lower means all new files are lower case now. But older mixed case named files become inaccessible over samba in weird ways. - like becoming not available as you've experienced. Glad this was all the source of your problem.

@CatMilk Not sure how the issue was fixed for you. Did you disable the case sensitive settings on the shares?