ken-ji

@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?

Hmm. You have case sensitivity turned on what I think are the affected shares; along with not preserving the case.... ie forcing them to all lowercase (the default) - on your shares... any particular reason? I think this might be what's giving you the unavailable error messages. all your samples that cannot be accessed anymore are mixed case. the one you said was fine is in all lowercase.

Nothing here stands out. Could you run testparm -s and paste the output of that? I'm wondering if you managed to have extended ACLs configured as that would cause samba to do some weird blocks if the extended ACLs got corrupted.

Hmm. what network is your nginx docker using? and did you assign the IP as well?

I will point out that this is my preferred setup that Unraid NAS + WebUI is only available on the main Network. If necessary, assigning an IP (statically or via DHCP) on the VLANs is also ok, but most users seem to get confused when the Unraid networking doesn't seem to work properly - and this is usually because the default route to reach the internet is going via a different VLAN/network interface than expected. I also use custom docker networks - since I need proper IPv6 support - though my Mikrotik router doesn't want to support DHCPv6, just SLAAC, and my ISP is doing fully dynamic /56 prefix allocation - which is a pain for Docker networks on IPv6 As long as the docker network is completely defined (subnet address and gateway) it will be available - your screen shots before did not have gateways assigned. I'll bet its because after configuring unraid not to get IP addresses for the VLANs, the lease is still considered live by your DHCP server. It should not be renewed after the typical 1day lease lifetime. Somewhere in the middle maybe typical depending on the DHCP server used. Some would do a hash of client MAC address and DUID to pick a suitable number in the leasing range. This means this host will likely get the same IP over and over (unless there are conflicts). Others just pick the next free and assign that.

You need to configure the network of the docker container to the correct one - br0.14 in your case. Also the docker network needs the correct gateway defined, otherwise docker will not be able to use it. - its 10.10.14.1 in your case. You also might not want to set an IP address and gateway for the VLAN in the Unraid network settings, so that Unraid will not be present on that VLAN. (or confuse you as Unraid tries to figure out which interface its supposed to use to go out to the internet.)

If you have VLAN support on your switch, you can set it up like this This will create subinterfaces eth0.x/br0.x (leaving bridging on is up to you as well as joining eth1). Then you configure the docker network on br0.x I just happen to have my nics split off and keep all my dockers on br1 (I set it up before the host access option for docker was there - haven't tested it if it'll work as like.) So my docker containers (like my nginx reverse proxy)

Looks good. I'll assume its working for you.