I tested this and I cannot replicate it. Although I wonder: can you look in your sites/default/files directory to see if the plant type image was uploaded there instead of sites/default/private/files? The former is “public” while the latter is “private”. If it’s in the “public” directory, that might suggest there’s a bug when farmOS is installed without a private filesystem configured… please let me know.
Edit: oops I mixed things up - disregard the above. (Although maybe still worth checking to see if anything was uploaded into sites/default/files public directory (or a subdirectory therein)…
Cross-posting Share your JupyterLite Examples - #7 by Symbioquine for future reference since some folks may find JupyterLite a compelling way to do their KML imports - especially if they need more control over how fields are mapped/transformed during import.
@Farmy Hmm it does look like your configuration is correct. Is this only affecting the KML import? Are you able to upload to assets/terms now?
What Docker image are you using? farmos/farmos:2.0.0-beta2? Or farmos/farmos:2.x-dev?
I see that sites/default/private/files has full write access to everyone, but it is owned by papa:papa. Normally you would have a group of www-data, and only owner/group write access. I’m curious if a kml directory exists inside files and what the ownership/permission of that is…
After much sleuthing and pain here’s how I ultimately solved the upload issue
Seems to be a filepath problem
remove the first slash as in change /opt/drupal/web/sites/default/private/files to opt/drupal/web/sites/default/private/files
The problem is solved. Not that I changed anything, but suddenly it worked. I just can imagine that certain caches were not flushed or any garbage collection didn’t work for hours. Is there any other way to flush caches except under Configuration - Development - Performance - Clear all caches?
