-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Picture not available when posting #211
Comments
Please try this branch : #210 |
Hello, thank for the quick answer. |
I didn't know about this method 🤔 Can you confirm you're using app version |
Yeah I wasn't sure about how to do it, tried your way, can confirm |
Could you please give me your instance url and diagnostics ? |
I replicated the issue on my test instance, same error logs, https://pixelfed.services.coupou.fr |
Here : https://pixelfed.services.coupou.fr/i/admin/diagnostics/home Be aware that it might contains information that you don't wanna share about your instance (config). Mainly domain name, which is already shared. I guess @neonota want to know if |
I get redirected to |
It's in your admin interface, in Diagnosis tab. |
Can't find it yet, I'll try again tonight, going for a long drive for now. |
You problem is same as @lapineige. Take a look at : pixelfed/pixelfed#4275 (comment) I've provided the correct config. It should resolve this issue permanently. Also don't forget to set |
Here's the link to Diagnostics page : https://yourserver.com/i/admin/diagnostics/home |
What's that ? |
If you set |
Here it is:
|
Some recommendations:
|
Did it fixed the issue ? |
I did that, thanks for the input
I modified /var/www/pixelfed/config/filesystems.php like this: <?php
return [
/*
|--------------------------------------------------------------------------
| Default Filesystem Disk
|--------------------------------------------------------------------------
|
| Here you may specify the default filesystem disk that should be used
| by the framework. The "local" disk, as well as a variety of cloud
| based disks are available to your application. Just store away!
|
*/
'default' => env('FILESYSTEM_DRIVER', 'local'),
/*
|--------------------------------------------------------------------------
| Default Cloud Filesystem Disk
|--------------------------------------------------------------------------
|
| Many applications store files both locally and in the cloud. For this
| reason, you may specify a default "cloud" driver here. This driver
| will be bound as the Cloud disk implementation in the container.
|
*/
'cloud' => env('FILESYSTEM_CLOUD', 's3'),
/*
|--------------------------------------------------------------------------
| Filesystem Disks
|--------------------------------------------------------------------------
|
| Here you may configure as many filesystem "disks" as you wish, and you
| may even configure multiple disks of the same driver. Defaults have
| been setup for each driver as an example of the required options.
|
| Supported Drivers: "local", "ftp", "sftp", "s3", "rackspace"
|
*/
'disks' => [
'local' => [
'driver' => 'local',
'root' => storage_path('app'),
'permissions' => [
'file' => [
'public' => 0664,
'private' => 0660,
],
'dir' => [
'public' => 0775,
'private' => 0770,
],
],
],
'public' => [
'driver' => 'local',
'root' => storage_path('app/public'),
'url' => env('APP_URL').'/storage',
'visibility' => 'public',
'throw' => true,
],
's3' => [
'driver' => 's3',
'key' => env('AWS_ACCESS_KEY_ID'),
'secret' => env('AWS_SECRET_ACCESS_KEY'),
'region' => env('AWS_DEFAULT_REGION'),
'bucket' => env('AWS_BUCKET'),
'visibility' => 'public',
'url' => env('AWS_URL'),
'endpoint' => env('AWS_ENDPOINT'),
'use_path_style_endpoint' => env('AWS_USE_PATH_STYLE_ENDPOINT', false),
'throw' => true,
],
'spaces' => [
'driver' => 's3',
'key' => env('DO_SPACES_KEY'),
'secret' => env('DO_SPACES_SECRET'),
'endpoint' => env('DO_SPACES_ENDPOINT'),
'region' => env('DO_SPACES_REGION'),
'bucket' => env('DO_SPACES_BUCKET'),
'visibility' => 'public',
'options' => [
'CacheControl' => 'max-age=31536000'
],
'root' => env('DO_SPACES_ROOT',''),
'throw' => true,
'url' => env('AWS_URL'),
],
'backup' => [
'driver' => env('PF_BACKUP_DRIVER', 's3'),
'visibility' => 'private',
'root' => env('PF_BACKUP_DRIVER', 'local') == 'local' ?
storage_path('app/backups/') :
env('PF_BACKUP_ROOT','/'),
'key' => env('PF_BACKUP_KEY'),
'secret' => env('PF_BACKUP_SECRET'),
'endpoint' => env('PF_BACKUP_ENDPOINT'),
'region' => env('PF_BACKUP_REGION'),
'bucket' => env('PF_BACKUP_BUCKET'),
],
],
]; did the artisan config:cache and cache:clear thing, restart both nginx and php8.1-fpm, did not fix the issue. |
Issue with changing umask is that it's a per-process setting, we can't set it for a specific directory, at least if we do it on the system side. Couldn't we set it somewhere in the application code? |
Why is that recommended ?
It should be enabled by default on Yunohost Pixelfed packaging 🤔
I don't know what it is 😄. I will search for it. |
I suggest that we bring back the conversation from #210 to this issue 🙂 |
I tried updating to 0.11.16 today, but unfortunately I am still having this issue :( It's definitely related to the directory permissions since I can get the uploaded files to be displayed by modifying the permissions on only the directories to 755. |
What directory do you change ? The last level (where the picture is), or an higher one ? |
We are making progress: https://forum.yunohost.org/t/pixelfed-pictures-not-loading/24244/34
I don't know how to change that behaviour… |
I'm guessing some process writing the files is running as pixelfed whereas it usually runs as www-data (in non ynh installations) |
It's actually very easy to fix. You guys are thinking in harder ways. |
Take a look at the last comment : pixelfed/pixelfed#4275 |
This hypothesis doesn't explain why changing rights to give read permission (because that should be the issue ?) to that hypothetical other process doesn't fix the mess 🤔 edit: more details here pixelfed/pixelfed#4275 (comment) |
So... In testing branch #215, I did some basic changes that should allow you to patch this as done here without relying on the command line. You only need to upgrade to that testing branch. It should fix the issue with existing broken files. What it does:
|
Thanks but since it does not fix the issue for new files I came up with a workaround. Until we come up with a fix, I'm using this script (I thought of using crontab to schedule it every x minutes, but it seemed overkill since I don't post that often, so I'm using rundeck to run it when needed):
It gives read/write to owner and group, read to others and execution to all only directories and already executable files.
You're right
What I don't understand is why the filesystems.php setting does not work. As for why the installation script chown command does not work, I'm clueless |
If you are using #215 this is no longer needed.
The same was proposed here : https://forum.yunohost.org/t/pixelfed-pictures-not-loading/24244/47 That might be a good workaround.
Yeah…
It does. The thing is newly created file are not controlled by this script. |
I don't know why I can't edit my previous message, so I'm adding my comment in this new one
You're right, but from what I understand php-fpm runs with the pixelfed user and thus it creates files owned by that user whereas nginx runs with the www-data user and nginx is indeed responsible for serving up the pages, that's why setting pixelfed as owner does not work. |
With the help of other contributors, in the related PR I made a change to pixelfed php settings, so it will be using I hope this will fix it… currently testing it. |
You may already try #215 : it should fix the issue on Pixelfed side ! 🎉 Not yet on Mastodon, we still need to figure out why. Thanks a lot to all people who contributed to solve this mystery ! 😃 |
I can confirm that fixed it, I'll just wait for it to be released to close the issue |
Can someone, having upgraded to #210 (0.11.6~ynh2), reproduce this pixelfed/pixelfed#4275 (comment) and tell us what is the group owner of a newly uploaded picture ? |
i am currently on 0.11.8~ynh1
|
Does it work from another software such as Mastodon ? |
I forgot to close this, it should be resolved with recent updates (#215, #217). See upstream conversation : pixelfed/pixelfed#4275 |
Describe the bug
When posting, the picture isn't displayed, , after selecting the picture, on the page where I should enter the caption, in place of the picture I have borken image link icon and if I proceed with the post, I have a "No preview available" as picture
Context
Steps to reproduce
I use the french version so my translations might not be perfect
Expected behavior
I can publish new post with working picture.
Logs
In nginx logs I can see after having selected the picture:
Permissions on the file are set as such:
PS: I tried changing permissions on the file but it does not change anything, tried forcing owner to pixelfed:www-data as well but it dit not work and any new upload is still owned by pixelfed:pixelfed
The text was updated successfully, but these errors were encountered: