Open lapineige opened 1 year ago
Great, that was fast, thanks a lot ! 🚀 We mainly depends on released version to upgrade, do you think you will make an hotfix for this, or should we try to upgrade to some specific commit (any advice ?) or to patch it ourselves ?
I tried manually using this commit (or rather a later one https://github.com/pixelfed/pixelfed/pull/4276), it still fails. Example : https://photo.lapineige.fr/i/web/post/548958694320755247
Just a random try of getting this fixed
can you try running php artisan storage:link
ERROR The [public/storage] link already exists.
How can I help to better diagnose this ?
How can I help to better diagnose this ?
I’m sorry that you haven’t received a response yet meanwhile I can suggest small steps
try restarting your server / or php artisan cache:clear
you can also check if horizon is running on admin dashboard horizon active or inactive
if inactive try php artisan horizon:publish and then run php artisan horizon
hope you will get this fixed soon
It's only been 3 days, no worries :)
Restart + cache:clear, no difference. Horizon is working, no failed job.
It's highly likely a permissions issue. Would you mind creating a account for me on your instance?
What do you mean by permissions ?
Account permissions (I'm admin), or file permissions ?
This wasn't a problem before upgrading to v0.11.5. I don't understand why any file permission would have changed since that time. And old images are shown.
I quickly checked, all files in /var/www/pixelfed
are owned by Pixelfed.
What do you mean by permissions ? Account permissions (I'm admin), or file permissions ? This wasn't a problem before upgrading to v0.11.5. I don't understand why any file permission would have changed since that time. And old images are shown. I quickly checked, all files in
/var/www/pixelfed
are owned by Pixelfed.
I'm talking about file permissions. Go to /var/www/pixelfed/public/storage and go deeper...
If I'm correct newly created folders should be owned by root. Create a user account on your instance and give me credentials.
Go to /var/www/pixelfed/public/storage and go deeper...
Everything is owned by pixelfed user. No change since the (working) state before the upgrade.
If I'm correct newly created folders should be owned by root.
Why is that ? Pixelfed user would not be able to access them ? 🤔
Go to /var/www/pixelfed/public/storage and go deeper...
Everything is owned by pixelfed user. No change since the (working) state before the upgrade.
If I'm correct newly created folders should be owned by root.
Why is that ? Pixelfed user would not be able to access them ? 🤔
Yeah .. That's the problem .. You need to modify config/filesystems.php to fix it. Set Dir public permissions to 0755 or 0775 and Dir Private Permission to 0770. For public files set permission to 0644 or 0664 and private files permission to 0660.
You need to modify config/filesystems.php to fix it.
How/why ? 🤔
What I don't understand is why it was working perfectly since that upgrade with folder and files owned by pixelfed users, and no longer since that upgrade. I don't understand why it should be owner by root.
edit:
Set Dir public permissions to 0755 or 0775 and Dir Private Permission to 0770. For public files set permission to 0644 or 0664 and private files permission to 0660.
You mean exactly as in this commit ? https://github.com/pixelfed/pixelfed/commit/22da2647c7f28f7e1d6a588f4549c3326aee9356 I don't have the same file here. This is very strange.
…
This is something very strange indeed:
Just in case I tried to run the artisan media:fix-nonlocal-driver
command as explained here https://github.com/pixelfed/pixelfed/pull/4278 (note: I'm not using S3)
Result: Command "media:fix-nonlocal-driver" is not defined.
But I upgraded to that precise commit, it should be included 🤔
So… for some reason the patch wasn't applied. I upgraded again to that version, the patch is here now, I have the filesystems.php changes, the new media:fix command is working (with no effect, as S3 is disabled).
But… it still doesn't work even with new media : https://photo.lapineige.fr/i/web/post/551045866359640065
Here's my filesystems.php:
What I don't understand is why it was working perfectly since that upgrade with folder and files owned by pixelfed users, and no longer since that upgrade. I don't understand why it should be owner by root.
Nor do I 😶 .. But this is how I fixed it.
Take a look at this: https://github.com/laravel/framework/issues/42586
Do you know where those files are stored so I can check manually before messing with all files rights and permissions ? 😅
Do you know where those files are stored so I can check manually before messing with all files rights and permissions ? 😅
Yeah ... Just upload an image ...
Open the image on a new tab from composer page.
You'll find the file path in the URL.
It should be /public/storage/m/_v2...
And it is only /storage/m/_v2/
, no public.
Even with that new version with this PR patch applied.
And it is only
/storage/m/_v2/
, no public. Even with that new version with this PR patch applied.
No. You have to go to /public/storage/m/_v2/
I mean if I upload a new image its URL is in /storage/m/_v2/
, not /public/storage/m/_v2/
.
If I search for it in /public/storage/m/_v2/
, I can find the file. It's owned by pixelfed user, and readable by all.
But the URL is wrong ?
I mean if I upload a new image its URL is in
/storage/m/_v2/
, not/public/storage/m/_v2/
. If I search for it in/public/storage/m/_v2/
, I can find the file. It's owned by pixelfed user, and readable by all. But the URL is wrong ?
No, the url is not wrong. Your root directory is set to /public . That's why it won't show up in the URL.
I mean if I upload a new image its URL is in
/storage/m/_v2/
, not/public/storage/m/_v2/
. If I search for it in/public/storage/m/_v2/
, I can find the file. It's owned by pixelfed user, and readable by all. But the URL is wrong ?No, the url is not wrong. Your root directory is set to /public . That's why it won't show up in the URL.
Can you confirm that the permission of the directory that contains the actual image preview isn't set to 0700?
Another question, have you disabled Image Optimization? If not, what's the image quality?
Can you confirm that the permission of the directory that contains the actual image preview isn't set to 0700?
It is set to 0700. Should I change it ? To what value ?
Another question, have you disabled Image Optimization? If not, what's the image quality?
I don't remember where I can check that. Can you help me on this ?
Can you confirm that the permission of the directory that contains the actual image preview isn't set to 0700?
It is set to 0700. Should I change it ? To what value ?
Another question, have you disabled Image Optimization? If not, what's the image quality?
I don't remember where I can check that. Can you help me on this ?
Go to Admin Dashboard > Diagnostics and Copy.
Then paste here.
It is set to 0700. Should I change it ? To what value ?
That's the problem. Go to /var/www/pixelfed/config and give me a screenshot of the filesystems.php file.
filesystems.php
: https://pastebin.com/rZGiLyb8
Looking for this I guess:
'disks' => [
'local' => [
'driver' => 'local',
'root' => storage_path('app'),
'permissions' => [
'file' => [
'public' => 0644,
'private' => 0600,
],
'dir' => [
'public' => 0755,
'private' => 0700,
],
],
],
And : PF_OPTIMIZE_IMAGES is set to false (thanks for the tip)
filesystems.php
: https://pastebin.com/rZGiLyb8Looking for this I guess:
'disks' => [ 'local' => [ 'driver' => 'local', 'root' => storage_path('app'), 'permissions' => [ 'file' => [ 'public' => 0644, 'private' => 0600, ], 'dir' => [ 'public' => 0755, 'private' => 0700, ], ], ],
And : PF_OPTIMIZE_IMAGES is set to false (thanks for the tip)
Change private file
permission to 660
and private dir
permission to 770
. It should fix the issue.
Also try to set PF_OPTIMIZE_IMAGES
to 95
Change private file permission to 660 and private dir permission to 770 . It should fix the issue.
You mean in the script (then why is it wrong in the first place ? 🤔) or in my filesystem ?
Also try to set PF_OPTIMIZE_IMAGES to 95
I don't want to set PF_OPTIMIZE_IMAGES, it destroys my image quality, and I already tweak them finely.
Change private file permission to 660 and private dir permission to 770 . It should fix the issue.
You mean in the script (then why is it wrong in the first place ? 🤔) or in my filesystem ?
Also try to set PF_OPTIMIZE_IMAGES to 95
I don't want to set PF_OPTIMIZE_IMAGES, it destroys my image quality, and I already tweak them finely.
Change permissions in the filesystems.php file
I tried, restarted php, did artisan cache:clear
.
No change. New files are created with rw-r--r--. It still doesn't work in the web UI.
Also I noticed that if I quit during the creation of a new post, the image is still kept in storage. Isn't that worth opening a new issue ? :thinking: And is there a way to cleanup those orphaned media files ?
I tried, restarted php, did
artisan cache:clear
. No change. New files are created with rw-r--r--. It still doesn't work in the web UI.Also I noticed that if I quit during the creation of a new post, the image is still kept in storage. Isn't that worth opening a new issue ? 🤔 And is there a way to cleanup those orphaned media files ?
We already discussed multiple time about this issue on Discord and Matrix Channel.
Last thing you can try is to enable Image Optimization and set its quality to 95
I may try it as a debugging solution, but I don't want to activate it definitely. I don't see why with this patch and the new permission that it sets, the results is not way is expected, and the files rights somewhat wrong if I understand well, should be a normal situation. Surely there still is (another ?) bug, isn't it ?
@dansup would you mind reopening please ? edit : thank you.
I will be happy to help understanding what is the issue if you have any test that I could run. (And by the way, thank @neonota for your time and help, it feels like we're making progress :)
I tried, restarted php, did
artisan cache:clear
.
@lapineige You need to run php artisan config:cache
and php artisan cache:clear
.
The first command, php artisan config:cache
will re-cache all config/*.php
files with .env
values.
The second command php artisan cache:clear
clears the app cache which is used as another level of caching for certain config settings.
Thanks a lot for explaining all that, I never found an explanation of what those commands would produce. I suppose restarting php will do none of that ?
The first command, php artisan config:cache will re-cache all config/*.php files with .env values.
Now I see why it's important to run it after an upgrade.
The second command php artisan cache:clear clears the app cache which is used as another level of caching for certain config settings.
And also for keeping the session open, right ? (it disconnects after that)
Sadly, I ran these two commands in that order, the issue is still there :(
I'm not the only one affected : several people (including this one https://github.com/YunoHost-Apps/pixelfed_ynh/issues/211#issuecomment-1518984383) reported to me that the upgrade containing this fix doesn't fix it. This might be a Yunohost miss-configuration, but I don't see why it would be an issue now and not before the upgrade.
I'm not the only one affected : several people (including this one YunoHost-Apps/pixelfed_ynh#211 (comment)) reported to me that the upgrade containing this fix doesn't fix it. This might be a Yunohost miss-configuration, but I don't see why it would be an issue now and not before the upgrade.
Did you change the permissions in filesystems.php as I said earlier?
Yes I did (here https://github.com/pixelfed/pixelfed/issues/4275#issuecomment-1509686959).
On user reported to me that doing a chmod -R 775
to the upload folder solve the issue in their case. See: https://forum.yunohost.org/t/pixelfed-storage-permission/24481/
I tried something new. I changed the filesystems.php
permissions like this:
'file' => [
'public' => 0665, // was 0660 as suggested here
'private' => 0600,
],
'dir' => [
'public' => 0775, // was 0660 as suggested here
'private' => 0700,
Did the config:cache and cache:clear thing. Uploaded file permission were: 665. Directory permission where… 700.
Do I guess well if I say it's a private directory with a public picture ?
On user reported to me that doing a
chmod -R 775
to the upload folder solve the issue in their case. See: https://forum.yunohost.org/t/pixelfed-storage-permission/24481/I tried something new. I changed the
filesystems.php
permissions like this:'file' => [ 'public' => 0665, // was 0660 as suggested here 'private' => 0600, ], 'dir' => [ 'public' => 0775, // was 0660 as suggested here 'private' => 0700,
Did the config:cache and cache:clear thing. Uploaded file permission were: 665. Directory permission where… 700.
Do I guess well if I say it's a private directory with a public picture ?
This is the correct config :
'file' => [ 'public' => 0664, // was 0660 as suggested here 'private' => 0660, ], 'dir' => [ 'public' => 0775, // was 0660 as suggested here 'private' => 0770,
So it's not like that https://github.com/pixelfed/pixelfed/issues/4275#issuecomment-1501166731 ? That 0664 is correct ?
I will try for the private folders. Edit: still fails :( Folder is 750 (???, I wrote the same as you did…), file is 664.
By the way, what is the difference between public and private folders in Pixelfed ?
So it's not like that #4275 (comment) ? That 0664 is correct ?
I will try for the private folders. Edit: still fails :( Folder is 750 (???, I wrote the same as you did…), file is 664.
By the way, what is the difference between public and private folders in Pixelfed ?
Private Folder > 770 Public Folder > 775 (not 750) ....
Private File > 660 Public File > 664
Yes that is what I used. But the result is 0750 🤔
I have the same issue. I mounted a local path as a docker volume. The thing is that I also use S3. The files are correctly uploaded to S3.
I tried:
filesystems.php
to reflect the values @neonota mentioned;config:cache
and cache:clear
chmod -R 775
to the uploading folder.Nothing seems to solved this.
I have the same issue. I mounted a local path as a docker volume. The thing is that I also use S3. The files are correctly uploaded to S3.
I tried:
- changing the
filesystems.php
to reflect the values @neonota mentioned;- running
config:cache
andcache:clear
- applying a
chmod -R 775
to the uploading folder.Nothing seems to solved this.
I use S3, so my problem is likely unrelated. I fixed it by adding the bucket name to the APP_URL.
Private Folder > 770 Public Folder > 775 (not 750) .... Private File > 660 Public File > 664
Several people reported that they used this with no success. (example here https://github.com/YunoHost-Apps/pixelfed_ynh/pull/210#issuecomment-1529249618)
One or maybe two reported they did an upgrade and had no change in the filesystems.php
, just as it was the case for me the first time.
I persist to think there is a bug, but I can't find if it's on Yunohost side or rather in Pixelfed itself.
For the record, I tried to upgrade to this commit : https://github.com/pixelfed/pixelfed/pull/4287
With no change regarding this issue.
Also filesystems.php
wasn't affected, no change in that file.
I wonder why an upgrade don't overwrite those files content. Any idea ?
Hello,
On Yunohost installations, since version 0.11.5 new uploaded pictures are broken. They are not shown, neither the preview is. Even in compose view. Alternative text is working. I don't really know how to debug this. No horizon failed job, no supervisor issue, I can't find laravel log, no web console error… No other error to report. You can see an example here : https://photo.lapineige.fr/i/web/post/548580903387685397
Is that a know Pixelfed bug ? How can I diagnose this ?
Thank you
Pixelfed : 0.11.5 Postgres: 13.9 PHP: 8.1 - recently upgraded, before Pixelfed 0.11.5 we were using php 8.0 Laravel : 9.52.4