daemons are unable to access files or folders

Go to System Preferences -> Security and Privacy -> Full Disk Access

Those daemons should be there for you to give them permissions.

My system is showing smbd, sshd.. among others there.

They are being denied file access until you enable them. Weird, I know..

This appears related to what I'm experiencing with CrushFTP. I kept the user directories in Documents, but I can no longer map CrushFTP's "virtual directories" to Documents or Desktop (I didn't think to try Downloads.) My workaround has simply been to no longer keep the user directories in iCloud (this had been convenient as I could maintain the contents on my main machine, and have them automatically sync to the one running the server.)

I'm having similar problems. As soon as i launched MacOS Catalina 10.15 Beta (19A487l) my files were gone. The desktop is completly empty, and when I search for the origonal files and try to open it, i get the prompt

The application “Finder” can’t be opened.
-36

Anybody else in this boat with me?

I work for an enterprise with 100+ machines running. Giving permissions for each user on every machine manually is not a feasible solution.

Is there any other way to give permissions programatically or by using MDM?

Same behavior for me in the Java Swing app I work on. When I open my file dialogs, I do not get the macOS system dialog asking for permission to access Desktop/Documents/Downloads. Adding my app to the Full Disk Access has no effect. I'm looking for a workaround but so far nothing.

Yes this would be the logical solution, except that LaunchAgents and Daemons are greyed out. You are not able to manually grant access to anything that is not an application.

Same problem here with a setuid root daemon on Catalina; granted full disk access to it, rebooted, but still "Operation not permitted". The only thing that does work for sure is to disable SIP, making it clear the issue is SIP related. Looking for a better solution, but..

Found the solution for my issue: giving /bin/sh "Full Disk Access" got the daemon to start and operate correctly.

I noticed if I started the daemon in the foreground from a terminal, it operated fine. But if started from launchd, it couldn't access anything. The only thing I can think of is the daemon's launch agent .plist file's <key>Program</key> entry points to a /bin/sh script that actually starts the daemon (to ensure the PATH is correct, and various flags like coredump size unlimited, and some other checks to see if networking and file server access is operating before starting the actual daemon)

Giving "Full Disk Access" to your shell (/bin/sh or /bin/bash) would work but it's a manual process you cannot script/automate (something fundamental when crafting a CI system for example).

A better solution is to move the files that need to be accessed/run by your daemons/agents to a location that is not ~/Documents, ~/Desktop etc. ~/bin for instance, works just fine.

Same issue occurs when deamons are run by launchcontrol on Sonoma with Raid disk arrays, suddenly even though the deamon is run as user 'root' it cannot access the raid drive, however if the same program is run from the shell prompt it works fine. I'm attempting to fix by moving the binary into the applications folder and granting it full disk access.