bmartino1

idealy a before and after I want the sys log and double check some setting to atempte to reproduce.

again, please give an updated diag file...

Please post an updated daig file.

https://github.com/lemker/unifi-os-server/issues/69 This has nothign to do with the docker and everything to do with how you're handling shares on unraid! Any and all dockers that rely on state files and the state files move or are no longer in the path before mover touches them! EVEN IN THE UNRIAD DOCS! https://docs.unraid.net/unraid-os/using-unraid-to/run-docker-containers/managing-and-customizing-containers/ Shares | Unraid DocsA key feature of Unraid is the management of shares. Shares are folders or drives on your Unraid server that can be accessed over a network. You can create as many shares as you want on your Unraid se Goes over that appdata SHOULDN'T be on more then 1 location for Docker! That is entirely user error.

If I were to guess, as I've seen it with other Unifi Docker there is an error and a log spam that fills Unraid's Docker image and causes lockouts. I have not seen this with the reborn controller.

Connect container to network docker network connect app-net myapp Brandon Martino - Personal SiteGuide-DockerNetworksBrandon Martino - Personal Site

These were working features in the SSH config tool back in unraid v6

but write data to ram os sytem doen't surive a reboot. again the ssh plugin and web ui... as this makes and writes the created users to survive a reboot. https://github.com/docgyver/unraid-v6-plugins/blob/master/ssh.plg learn from it if you want cli and how unraid needs to handle the shadows and tdb user database...

https://forums.unraid.net/topic/178033-bmartino1-user-scripts/page/2/#findComment-1598908 ... then find the memory leak here is how you can...

thank you for posting diagnostics. as you clearly edited or added into smb extra to make your winbind ad (not samba defult) quote: Here is some info that might help knowing to help troubleshoot: net ads testjoin version="7.2.3" 6.12.54-Unraid 16:28:52 up 1 day, 8:05, 0 users, load average: 4.57, 4.76, 4.66 Version 4.23.4 Ping to winbindd succeeded checking the trust secret for domain MTSEYMOUR via RPC calls succeeded Workgroup: MTSEYMOUR Realm: MTSEYMOUR.CA Bind Path: dc=MTSEYMOUR,dc=CA LDAP port: 389 Server time: Mon, 16 Mar 2026 16:28:52 PDT KDC server: 192.168.1.4 Server time offset: 0 Join is OK per diag and data I'm still at a widnows server ldap issues and posix gid/pid... Samba/AD identity mapping is working enough to authenticate users, but the underlying Unraid share permissions or ACL expectations do not line up with those mapped IDs/groups. So the pattern is: user authenticates through AD Samba maps them to a UID/GID via winbind/rid Samba tries to enter /mnt/user/<share> Linux/Unraid permissions on that share deny access Samba logs vfs_ChDir(... ) failed: Permission denied That is a permissions/ACL/idmap mismatch problem first. Not a network outage first. Not a disk error first. Not a Kuma ping/TCP monitor first. What I do see that is worth paying attention to: a lot of custom plugins autotweak unassigned.devices unassigned.devices.plus ipmi old/deprecated plugins custom Samba AD config remote SMB mounts via Unassigned Devices, including failed CIFS mount attempts That combination is enough that I would not assume “stock Unraid behavior” anymore. As jorge has mentions to start narowing it down and fixing things would be to remove the custom confiruagation tnd get unriad base stable. One especially suspicious thing Unassigned Devices is trying to mount remote SMB shares and some are failing: Remote Share '//192.168.0.2/test' failed to mount. CIFS: VFS: cifs_mount failed w/return code = -13-13 is permission denied. That is not proof UD is breaking local Samba, but it does reinforce the broader theme: there are multiple SMB/permissions/authentication layers in play here, and at least one of them is already misaligned. My read of the likely root causeMost likely: AD/winbind/idmap was added or adjusted, but the actual Linux-side share ownership/ACLs on the Unraid filesystem were not fully rebuilt to match the AD-backed access model. That would explain why: multiple users authenticate multiple shares fail failures happen repeatedly the token UIDs/GIDs look like domain-mapped IDs the problem appears intermittent from the user side but is actually permission-dependent per share/session But again asumptions. So lets double check. Verify the AD mapping itself Run: wbinfo -u | head wbinfo -g | head getent passwd 'DOMAINUSER' getent group 'DOMAINGROUP'They need to confirm winbind is resolving users/groups consistently. Check actual permissions on failing sharesFor a failing share: namei -om /mnt/user/"Password Manager" getfacl /mnt/user/"Password Manager" ls -ld /mnt/user/"Password Manager" ls -ld /mnt/disk*/"Password Manager" 2>/dev/nullThat will show whether /mnt/user/... and the underlying disk paths actually permit traversal for the mapped AD user/group. Check whether ACLs exist but are wrongBecause with AD on Unraid, the issue is often not authentication itself but directory execute/traverse bits and ACL inheritance. Temporarily remove the custom Samba overlay(this is what jorge is saying...) Not necessarily delete it, but move /boot/config/smb-extra.conf out of the way and test with a simpler config if possible. If the issue vanishes, that confirms the custom ADS layer is central. Strip plugins down while testingFor the intermittent management access problem, I would especially test with these disabled first: autotweak unassigned devices / remote SMB automounts any plugin modifying nginx/php/webgui behavior deprecated plugins still hanging around This may be muti plugin issues and conflicts... So there are likely two issuesif not more...: A. SMB/AD permissions mismatchcausing share access failures B. WebUI/PHP worker exhaustioncausing management timeout symptoms #SOLUTIONS############### *try this for smb extra. [global] workgroup = MTSEYMOUR security = ADS realm = MTSEYMOUR.CA local master = no preferred master = no domain master = no winbind use default domain = yes winbind enum users = yes winbind enum groups = yes winbind nested groups = yes winbind refresh tickets = yes dedicated keytab file = /etc/krb5.keytab kerberos method = secrets and keytab idmap config * : backend = tdb idmap config * : range = 3000-7999 idmap config MTSEYMOUR : backend = rid idmap config MTSEYMOUR : range = 10000-999999 winbind cache time = 300 idmap cache time = 300 No full-file override. No immutable flag. No manual [global] duplication elsewhere. No forced root shares unless there is a very special one-off need. Remove the override script from startupI would disable that script completely for now. If they want a “recovery” script, make it a plain Samba restart script, not a file replacement script. Example: #!/bin/bash logger -t RestartShareServices "Restarting Samba cleanly" /etc/rc.d/rc.samba restartBut for diagnosis, even that should be manual first. verify the mapped AD identitiesRun these on the box: wbinfo -u | head -50 wbinfo -g | head -50 getent passwd "some_ad_user" getent group "Domain Users"Also for one failing user from the logs: id "that_user"We want to confirm the AD user resolves consistently and that the expected domain groups are present. inspect one failing share all the way down Pick one failing share, like ReportServer or Bulletin-Board, and run: namei -om /mnt/user/ReportServer getfacl -p /mnt/user/ReportServer ls -ld /mnt/user/ReportServer ls -ld /mnt/disk*/ReportServer 2>/dev/nullThis is where the truth will be. Because Samba is already showing us the mapped token, for example: uid=11135 gid=10515 groups: 11135 10515 3003 3004 3005If that token cannot traverse the share path, Linux will deny it no matter how good the AD join is. What I strongly suspect is wrongOne or more of these is likely true: share path ownership is still nobody:users with restrictive mode bits execute/traverse bit is missing on a parent directory underlying /mnt/diskX/share permissions differ from /mnt/user/share ACL inheritance is inconsistent across disks some shares were created before AD integration and never re-permissioned for domain groups That would perfectly match the repeated vfs_ChDir(... Permission denied) messages. About “correct gids”With RID idmap, the GIDs are not something you should hand-author into Samba share stanzas. They are generated from the domain SID mapping. So the right move is: keep RID mapping stable verify the intended AD group grant filesystem permissions/ACLs to that mapped group Not: force group = root force user = root rewrite smb.conf to pretend the IDs are different On the WebUI timeoutsThat php-fpm max_children warning is worth addressing separately. It suggests the UI is being starved of PHP workers. That can come from: heavy dashboard polling plugins diagnostics pages lots of active tabs/widgets I would trim plugin load while troubleshooting, especially anything nonessential. The SMB problem is likely independent, but the WebUI timeouts are making the whole situation harder to work on. This is signs of sytem exhaustion and a potentail memory leak... review: and that go over editing fasctcgi adn openign up the fasct cgi info statu page to see what may be runnign previenting ssh/webui access.

the system monitoring may be causing ghost / cashed session to reactive adn given the other data ps aux | grep smbd | wc -l ps aux | grep smbd | head -50 this looks like smb connections and reconencitons due to whats singed and currently connected to the system. example: What your screenshot shows is a very specific Samba failure pattern that happens when an SMB client session still exists but the filesystem permissions or mount state underneath the share has changed. The repeating error line is the key: vfs_ChDir(/mnt/user/... ) chdir_current_service: failed: Permission denied. Current token: uid=12192, gid=10515, 7 groups: ...That tells us several important things. What the log actually meansSamba is trying to switch the working directory of an already-connected client session. Internally Samba does: chdir("/mnt/user/<share>/<path>")But the UNIX permissions for the UID/GID token Samba is using no longer allow access. his happens in Unraid most often when one of these occurs: Cached SMB sessions after permission changesExample sequence: Windows client connects to share You run Docker/Unraid tools that change UID/GID Existing SMB session still uses old idmap token Next filesystem access → Permission denied The Samba session keeps retrying → you get spam like your screenshot. but this is and assumption. diagnostic file would help. UID/GID mapping mismatch (possible from your output)Your idmap configuration: idmap config mtseymour : backend = rid idmap config mtseymour : range = 10000-999999 idmap config * : backend = tdb idmap config * : range = 3000-7999The log shows: uid=12192 gid=10515So Samba generated a mapped domain UID, but the filesystem likely expects nobody:users (99:100) or another fixed mapping. This mismatch is very common on Unraid when: AD/LDAP was previously configured idmap changed cached tokens still exist Run this on Unraid: smbstatusLook for: PID Username Group Machine -----------------------------------------and Service pid machine -----------------------------------------If you see the same client repeatedly accessing the share → that's your spam source.

at that point and level your better of writing your own smb config. see script here: that said deadtime while it will help kill dead/stale connections may not be the answer per data shown... you have some form or kind of tracking that is creating or makeing a conenction to test nad that test is going crazy given the pitures and parts of teh data listed with in...

@dopeytree Thank you again squid for your time FYI as it took me a min to reference what squid was saying In unraid CA: here we can hit: and get the data we need: Then correct what we must to add to CA.

thank you this helps me quite a bit. I've also noticed that recent unraid template authoring is not generating the XML correctly, even though the gui is set and i can make it run.. .teh xml authoing mode for save is making a long list of -p ports into -v, for example, some of this is indeed just xml editing. It would be nice to have an example template to fill. https://forums.unraid.net/topic/38619-docker-template-xml-schema/ as I can see icloud pd inteh CA that is in the github deprecated folder: https://unraid.net/community/apps but not when searching on uraid CA.

made a unriad XML adding to CA now with recommended updates. https://github.com/bmartino1/unraid-docker-templates/blob/main/unifi-os-server.xml so os should be avilable latter tonight/tomorrow hopefully. Its Alive

you can test archive by foring a archive... go to playback and select a detection.. and with the selection hit archive to nas ip / unraid... it... thats it you will then see the detection on the unraid nas... so the 0 bytes is noraml .. and current detections need archived and new should auto once quot/retention is hit. takes a while for it to report and update data... if you manualy sent detections...

your pictures broke up let me retest and re go over an example setup. To be clear You shouldn't need to replace samba! I replace unraid samba for my own. as seen here: idealy you will need to seutp a unfi protect share: in my case I'm also using zfs zfs create data/unifi-protect as I'm using my own smb extra and not using unraid shares: example share data: [samba] create mask = 0775 force create mode = 0777 force directory mode = 0777 force group = root force user = root guest ok = Yes map hidden = Yes map system = Yes path = /host/samba read only = No fruit:encoding = nativeSo, I will make a new share with my own custom settings. that can be saved with the global smb2 info under the smb extra options... root@OMV:/host# ls Dockers/ PBS/ PVE/ TimeMachine/ Users/ samba/ unifi-protect/ root@OMV:/host# and since I'm overiding unraids config: root@OMV:/boot/config# ls Basic.key domain.cfg go machine-id plugins/ random-seed share.cfg ssh/ default/ drift go~ modprobe.d/ plugins-error/ savedpcidata.json shares/ ssl/ disk.cfg editor.cfg hosts network.cfg plugins-removed/ secrets.tdb smb-override.conf super.dat docker.cfg forcesync ident.cfg passwd pools/ shadow smbpasswd wireguard/ root@OMV:/boot/config# nano smb-override.conf if using the user script to make your own share for all... I would add my own custom share setting... *this is the same samba I'm running and shared in the user scripts forum post above... You shouldn't have to replace samba and you can't use unraids share setting for the share for the same item... instead you can add this to the smb extra and use that to make a custom share for unifi example: confirm with root@OMV:~# testparm so now I have a share called unifi from my unraid system... Since your seeing a connect but no data... you may need to fix / set permissions... root@OMV:/host# chmod 777 -R unifi-protect/ root@OMV:/host# chown nobody:users -R unifi-protect/ You should now see a unifi share in unraid: Now on unifi: in unifi protect go to settings: I first go to add account then select nas: and fill in data: *Connect with a made unraid user.. made in the users tab in web ui: choose the share: with that the nas folder is linked: then enable Continuous Archiving and add the cameras you want data saved to protect: select dection.... click apply 0b is normal to see... as the Continuous Archiving kicks in once the unifi device hits its limit on space / quota.. see https://community.ui.com/questions/UniFi-Protect-with-external-NAS/c6f24e56-f650-4bf6-818b-0323aa927257?reply=2 and https://community.ui.com/questions/Archiving-ALL-Detections-to-NAS/74fb9819-d8d3-42af-a0c8-b3410f725c86 so I think your confused as you seem to have the share setup corectly... abd are corecty connected and unifi when it hits the camera space and detection at next run will save when unifi storage quota is hit and it will move/save the data on the nas before erasing... I'm not aware of any other issue and this has been the sucessful setup betweeen other unfi setups i've done int eh past with unraid.. othewise i just finsihed adding unfi server os where you can run unifi protect via docker on unraid and have protect conect and save data on unraid via docker volume pathing...

Depends on what you're trying to do now with it. Like explained in the above post... Unify United system and unified protect requires smb2 protocol On unraid you have to turn off the array, go to settings SMB and add these lines to the SMB extra.. [global] server min protocol = SMB2 server max protocol = SMB3 This seems to have done the trick now.... Is noted above... With this, your UniFi NVR device and your cameras can point to the network share on unraid so where samba and copy the data off and into the share. Otherwise you install a VM. You install Debian And you install UniFi protect and the UniFi console in a VM. And using Debbie and samba connection you connect to your your virtual iofs and/SMB tonu raid And use the UniFi console and even if I protect on that VM... with the release of unfi OS for a VM I would recemd runing a debain VM and ther unfi stack there any more... ITAdOn IT SolutionsUbiquiti introduces UniFi OS Server for self-hostingUbiquiti has just launched the UniFi OS Server in Early Access, enabling users to self-host the full UniFi network stack on their own hardware. And data here GitHubGitHub - lemker/unifi-os-server: Run UniFi OS Server in D...Run UniFi OS Server in Docker or Kubernetes. Contribute to lemker/unifi-os-server development by creating an account on GitHub.

If it's port locking, it's usually port 1900, the turn/stun port that is often found alongside media servers like Plex and Jellyfin. unifi using port 1900 for it internal unifi talk structure... I would make a new Docker network bridge and try it again... or move the reborn docker to its own custom ip https://bmartino1.weebly.com/guide-dockernetworks.html

That is correct, the only thing someone needs to do is set the app data folder. The only piece of inofmration that chagnes. also per the 1st post of this forum when setting your plex path in the tempate you must see the Library folder. no other settng change is required. Per your post your running if you edit the old docker enable teh advance togle at the top top right. then Scroll down down to bottom and show more settings. You will see an appdata path. COPY THAT PATH! Per that appdata default template path is /mnt/user/appdata/plex so you would change the first option in my template to that path...that's it.. as it say in yellow. WHEN DONE CORRECTLY! You should see the Library Folder. This is the only thing that needs editing to run automatic repair... This is user preference and customizeable this is why a default location is not set and can't be set as not all templates use the same path...

fff fix no there OG OP was more on wher teh fiel was located then why the plugis docker compose plugin comand while exist is not in place any more.. Thus teh reason I gave root@OMV:/host/Dockers/immich# docker compse --help as it used to be docker-compse --help Which was udpated with small implementsaoin to teh docker udpoate and how unraid is trying to incoperate teh updated binary.

https://docs.docker.com/guides/docker-compose/why/ that depends. did you set teh stack setting at creation? Example: at creation your able to spefic the path where the .env envioirment file and docker-compose file exists. if you already made the stack by editing the stack document the plugin tells you where the saved file is: example immich I set it to: "/host/Dockers/immich/docker-compose.yml" permsion should follow unriad docker safe permissions of chmod 777 and chown nobody:users. unless specfic docker permision are mention and applied. IF YOU DONT set the advance specifed location I believe it defults to the unraid flash drive somewhere in the plugin directory found somewhere in /boot simlar when you save the stack UI lables of the docker-override for the stack that the plugin auto adds now. This is what sets the runnign dockers at the top to be and say dockerman, have the icon and ui web link if set. root@OMV:/boot/config/plugins/compose.manager/projects# ls Immich/ Tailscale_TSDproxy/ version root@OMV:/boot/config/plugins/compose.manager/projects# cd Immich/ root@OMV:/boot/config/plugins/compose.manager/projects/Immich# ls autostart docker-compose.override.yml indirect name root@OMV:/boot/config/plugins/compose.manager/projects/Immich# Its been a while I think it defaults to this path on the usb if not set... example following the immich docker guide Brandon Martino - Personal SiteImmich-on-Unraid-Docker-Compose-GuideBrandon Martino - Personal Siteand adding example label assist and sets ui lables at frist edit save prompt. labels: net.unraid.docker.icon: 'https://raw.githubusercontent.com/A75G/docker-templates/master/templates/icons/redis.png' folder.view: immich net.unraid.docker.managed: 'composeman'saving the ui stack lables adds them to the overrid compose file in the plugin folder whcih overwrites edits nt eh main compose writen which is why secondary edits dont' get applied as teh plugin refers to teh override due to plugin need aspects for teh docker page and emhttp intergration. So the question then becomes when you edit the stack and edit the enviroment .env file of compose file what does the text editor/ manger says your file is located at... then we can use user scripts and otehr termanl comands like docker compose down and docker compose up in that folder where the compsoe file is to turn off and on dockers (sometiems needed when using the appdata backup plugin.) root@OMV:/host/Dockers/immich# docker compse --help Usage: docker [OPTIONS] COMMAND A self-sufficient runtime for containers Common Commands: run Create and run a new container from an image exec Execute a command in a running container ps List containers build Build an image from a Dockerfile pull Download an image from a registry push Upload an image to a registry images List images login Authenticate to a registry logout Log out from a registry search Search Docker Hub for images version Show the Docker version information info Display system-wide information Management Commands: builder Manage builds buildx* Docker Buildx compose* Docker Compose container Manage containers context Manage contexts image Manage images manifest Manage Docker image manifests and manifest lists network Manage networks plugin Manage plugins system Manage Docker trust Manage trust on Docker images volume Manage volumes Swarm Commands: swarm Manage Swarm Commands: attach Attach local standard input, output, and error streams to a running container commit Create a new image from a container's changes cp Copy files/folders between a container and the local filesystem create Create a new container diff Inspect changes to files or directories on a container's filesystem events Get real time events from the server export Export a container's filesystem as a tar archive history Show the history of an image import Import the contents from a tarball to create a filesystem image inspect Return low-level information on Docker objects kill Kill one or more running containers load Load an image from a tar archive or STDIN logs Fetch the logs of a container pause Pause all processes within one or more containers port List port mappings or a specific mapping for the container rename Rename a container restart Restart one or more containers rm Remove one or more containers rmi Remove one or more images save Save one or more images to a tar archive (streamed to STDOUT by default) start Start one or more stopped containers stats Display a live stream of container(s) resource usage statistics stop Stop one or more running containers tag Create a tag TARGET_IMAGE that refers to SOURCE_IMAGE top Display the running processes of a container unpause Unpause all processes within one or more containers update Update configuration of one or more containers wait Block until one or more containers stop, then print their exit codes Global Options: --config string Location of client config files (default "/root/.docker") -c, --context string Name of the context to use to connect to the daemon (overrides DOCKER_HOST env var and default context set with "docker context use") -D, --debug Enable debug mode -H, --host list Daemon socket to connect to -l, --log-level string Set the logging level ("debug", "info", "warn", "error", "fatal") (default "info") --tls Use TLS; implied by --tlsverify --tlscacert string Trust certs signed only by this CA (default "/root/.docker/ca.pem") --tlscert string Path to TLS certificate file (default "/root/.docker/cert.pem") --tlskey string Path to TLS key file (default "/root/.docker/key.pem") --tlsverify Use TLS and verify the remote -v, --version Print version information and quit Run 'docker COMMAND --help' for more information on a command. For more help on how to use Docker, head to https://docs.docker.com/go/guides/

its already in the CA:

Sounds like you want another ca unraid app for Docker management. It DockhandDockhand - Modern Docker ManagementA powerful, intuitive Docker platform for everyone. Real-time container management, Compose stacks, Git deployments, and SSO - all free.GitHubGitHub - Finsys/dockhand: Dockhand - Docker management yo...Dockhand - Docker management you will like. Contribute to Finsys/dockhand development by creating an account on GitHub. It would be a bit redundant but possible to run similar with running portainer on top of unraid. I can make a standalone XML unraid ca app of this dockerhand Mind you it will be the base application only no database companion.

in lattest unraid 7.2.4 there is a disply bug when opening the menu on a lxc the interal page lods a scroll wheel and requires scorll mous to access the lxc option menu not sure if a css page with or other needs updated in plugin.