pixelfed / pixelfed

Photo Sharing. For Everyone.
https://pixelfed.org
GNU Affero General Public License v3.0
5.61k stars 670 forks source link

Picture display broken after upgrade to v0.11.5 : folder rights issue #4275

Open lapineige opened 1 year ago

lapineige commented 1 year ago

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

dansup commented 1 year ago

Fixed in 22da264

lapineige commented 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 ?

lapineige commented 1 year ago

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

orangemelo11 commented 1 year ago

Just a random try of getting this fixed

can you try running php artisan storage:link

lapineige commented 1 year ago

ERROR The [public/storage] link already exists.

lapineige commented 1 year ago

How can I help to better diagnose this ?

orangemelo11 commented 1 year ago

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

lapineige commented 1 year ago

It's only been 3 days, no worries :)

Restart + cache:clear, no difference. Horizon is working, no failed job.

mitexleo commented 1 year ago

It's highly likely a permissions issue. Would you mind creating a account for me on your instance?

lapineige commented 1 year ago

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.

mitexleo commented 1 year ago

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...

mitexleo commented 1 year ago

If I'm correct newly created folders should be owned by root. Create a user account on your instance and give me credentials.

lapineige commented 1 year ago

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 ? 🤔

mitexleo commented 1 year ago

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.

lapineige commented 1 year ago

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 🤔

lapineige commented 1 year ago

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

mitexleo commented 1 year ago

Here's my filesystems.php: SmartSelect_20230410-214508_Termux

mitexleo commented 1 year ago

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

lapineige commented 1 year ago

Do you know where those files are stored so I can check manually before messing with all files rights and permissions ? 😅

mitexleo commented 1 year ago

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 ...

Screenshot_20230411-165403_Vivaldi Browser

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...

lapineige commented 1 year ago

And it is only /storage/m/_v2/, no public. Even with that new version with this PR patch applied.

mitexleo commented 1 year ago

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/

lapineige commented 1 year ago

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 ?

mitexleo commented 1 year ago

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.

mitexleo commented 1 year ago

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?

mitexleo commented 1 year ago

Another question, have you disabled Image Optimization? If not, what's the image quality?

lapineige commented 1 year ago
 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 ?

mitexleo commented 1 year ago
 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.

mitexleo commented 1 year ago

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.

lapineige commented 1 year ago

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)

mitexleo commented 1 year ago

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)

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

lapineige commented 1 year ago

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.

mitexleo commented 1 year ago

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

lapineige commented 1 year ago

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 ?

mitexleo commented 1 year ago

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

lapineige commented 1 year ago

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 :)

dansup commented 1 year ago

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.

lapineige commented 1 year ago

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 :(

lapineige commented 1 year ago

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.

mitexleo commented 1 year ago

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?

lapineige commented 1 year ago

Yes I did (here https://github.com/pixelfed/pixelfed/issues/4275#issuecomment-1509686959).

lapineige commented 1 year ago

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 ?

mitexleo commented 1 year ago

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,
lapineige commented 1 year ago

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 ?

mitexleo commented 1 year ago

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

lapineige commented 1 year ago

Yes that is what I used. But the result is 0750 🤔

oculos commented 1 year ago

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:

Nothing seems to solved this.

oculos commented 1 year ago

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 and cache: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.

lapineige commented 1 year ago

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.

lapineige commented 1 year ago

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 ?