I cannot upload any private files, I thought I had setup the directory correctly but perhaps I’m not. I am using docker for windows to host the driving end and my network db raspberry pi 4 (8gb ram) for the database server.
When I try and upload anything for any category it gives me a permissions error and I am unsure of how to fix this with WSL2 docker for windows system. I normally run everything on my many pi blades but I haven’t put in time to figure out how to actually deploy a container I can us for uploads for farmos-beta2.
Private file system path
opt/drupal/web/sites/default/private/files
but all uploads return
|Location|http://localhost:8081/asset/add/land?_wrapper_format=drupal_ajax&ajax_form=1&element_parents=file%2Fwidget|
|---|---|
|Referrer|http://localhost:8081/asset/add/land|
|Message|The upload directory private://farm/asset/2022-02 for the file field file could not be created or is not accessible. A newly uploaded file could not be saved in this directory as a consequence, and the upload was canceled.|
anyone who as experience with windows/wsl docker might be able to suggest how to go about investigating permissions? that’s where I would start if i was native in linux?
Okay, I’m running ubuntu 20.04 64 bit headless so that seems like it gives me a path, I’ve never built through docker, but it seems like it could be a useful skill!
Hi @usulrasolas welcome to the farmOS forum! Sorry to hear you’re having trouble with Windows + Docker volumes. That seems to be a common issue for folks (not just in the farmOS community). I would suggest searching the forum - there have been a few others who had the same problem and figured it out eventually… I don’t use Windows so I’m afraid I can’t be much help other than pointing you to the other forum topics…
I started there and joined to see if any new insights. I am going to try and build and deploy to my rpi4(8gb) as it was intended to be the host, just never got past bumbling with manual drupal installs so trying this build method as I have much more experience with docker on linux than wsl2.
Thanks for the welcome! We just moved to a new farm and started hatching ducks so I’m looking to get my records digital before they’re big enough to get banded.
@Farmer-Ed is debug needed? I am doing the build now, and intend to do my own compose with mariadb and adminer just for my own convenience and was looking at your example. Just curious how last two lines effect the entire install and are needed as I haven’t deployed like that previous?
No, I don’t believe they are required, and I should probably review my own instructions.
When you build the docker image, there will be a number of docker compose templates in the docker folder, I believe those debug options are only in the development template.
You should probably only bind mount the sites folder too not the entire drupal folder as it will make updating simpler in future.
‘./sites:/opt/drupal/web/sites’ instead of - ‘./www:/opt/drupal’
You’ll probably still have to deal with some folder permissions at the end too, but it sounds like you are familiar with Linux permissions already.
Oh and welcome along and good luck with the Ducks.
and using the docker build outlined in @Farmer-Ed linked post. But still pulling some error on upload but have more in error log this time?
4 instanced of:
*Warning* : is_dir(): Unable to find the wrapper "private" - did you forget to enable it when you configured PHP? in *Drupal\Core\File\FileSystem->prepareDirectory()* (line *539* of */opt/drupal/web/core/lib/Drupal/Core/File/FileSystem.php* )
followed by same message of
The upload directory *private://farm/asset/2022-02* for the file field *file* could not be created or is not accessible. A newly uploaded file could not be saved in this directory as a consequence, and the upload was canceled."
I am checking the media folder permissions and everything seems fine as well as I have tried to check if the config line in .php is wrong and I both opt/drupal/web/sites/default/private/files and /opt/drupal/web/sites/default/private/files seem to generate same. I can provide bigger log if needed.
Have you added the folder? its not there by default.
in settings.php I have these 2 settings configured for files folders. (adjust for your own folder if different) $settings['file_private_path'] = 'sites/private'; $settings['file_public_path'] = 'sites/default/files';
from your sites directory do ls -l owner and group of all files and directory’s should be www-data
same in sites/default
A quick Google, gave me this list for permissions:
Drupal webroot should be 0755
for public upload directories: 0755 or 0775
for private upload directories: 0750 or 0770
for public uploaded files: 0644 or 0664
for private uploaded files: 0640 or 0660
for .htaccess within upload directories 0444 or 0644
Just want to mention: I would recommend NOT using farmos:latest - and instead specifying the full version you want (eg: farmos:2.0.0-beta2). This will ensure that your upgrades are more intentional moving forward and you don’t accidentally end up upgrading without realizing it.
I almost removed the latest tag entirely for this reason, but @Symbioquineconvinced me to keep it.
The risk is that you upgrade unintentionally and then forget to run update.php. If there are critical database updates that need to be run between versions, and you don’t run them, it could lead to data corruption or unintended behaviors.
Don’t think it is currently likely to happen with the Pi Images as they are local image builds would take a few more steps to accidently upgrade, unless of course you add ARM support to your Docker images. But I’ll take that on board just in case.
I will check on this because the full path is the example on the install directions and that’s what I’ve been permutating, not the short (i assume?relative) path. (opt/drupal…) and that could break things easy enough too.
yes, I understand this. I am building for arm64 so I can deploy on rpi4, but this was similar on docker windows with beta2, wondering if it may just be relative vs absolute path, will let everyone know when I have time to poke at it. I hadn’t custom built any docker containers before, I will look into documents and see if I can pick specific builds to build locally. I don’t know if I have a upgrade risk with manual builds, but if farmos serves arm64 images at any time I think it would as mentioned above as well.
Seems like I have a possible issue based on my own methods that is similar between both installs and correlates to the logged issue… that’s a lot of correlation. Thanks y’all
Solved. It appears that following ALL the practices I could find fixed it. I believe (not 100%) that it wasn’t the relative vs absolute pathing as I have now had both take (I prefer absolute like in official install direction) but the fact that drupal wants the private to be outside the default sites folder.
Thanks to both ya’ll for the help, I’ll be sticking around and following stuff and am happy to help however I can. This seems to be the perfect project for my needs, I have already tried a lot of free trial alternatives and see no need to waste my money on that when I could donate to this project. Have I mentioned I love discourse and it’s great this project is using it?
Oh yes! I was just going to say the same… technically the file_private_path is supposed to be an absolute path - per the default.settings.php included with Drupal: 404 Not Found
$settings['file_private_path'] = '/opt/drupal/web/sites/private'
the fact that drupal wants the private to be outside the default sites folder.
Just to clarify… I think Drupal recommends putting the private files directory outside of the webroot - not outside of the sites/default directory. But this isn’t strictly necessary - just an extra paranoid approach. Drupal will (should!) automatically create a .htaccess file inside the private files directory that prevents anyone from accessing it publicly, and that’s generally “safe enough”.
Putting it in sites/private will have the same effect, but is kind of weird to be honest, just because it goes against “best practice” for recommended directory structure. Doesn’t really matter (it will still work!) but I would probably recommend either a) moving it back into sites/default/private, or b) moving it out of the webroot entirely.
This seems to be the perfect project for my needs, I have already tried a lot of free trial alternatives and see no need to waste my money on that when I could donate to this project. Have I mentioned I love discourse and it’s great this project is using it?
WSL doesn’t work for me no matter what I do, but given the rpi4 install works great, the original issue is moot/void.
But an update and question:
For the life of me, if I add /default back into sites/private then it fails, even when moving folder or recreating the folder with permissions. Which brings me to:
So, say I was going to plan this so I also have a secondary bind mount in my docker-compose to keep it consistent and accessbile for me, where WOULD be best practices say to put it? This refers to the internal docker location not the bind location just be perfectly clear. All my bound folders are inside their respective container/stack folders inside the docker user home folder.
Any suggestions would be great, just dunno what correct practice would be, but this is working fine for now lolol
One directory up from the webroot is a good place to put it. So inside the Docker container that would be /opt/drupal/keys (alongside the webroot /opt/drupal/web).
Glad to hear you got it all working! Sorry to hear WSL was troublesome, and that the /default didn’t work – very odd.
This may be too basic but, we had no problem with Wsl and docker on the interns laptop and couldn’t get it to load on our desktop computers. We discovered WSL and docker only works on windows 10 pro not the free home version. $99.00 solves the problem.
Never tried it myself, but the Microsoft tutorial on WSL + Docker doesn’t seem to indicate that W10 Pro is needed - only “version 2004, Build 18362 or later”.
Thanks y’all
Glad to have you 
