I have had the same issue since the 11.5 update. I applied the testing branch upgrade, ran the two artisan commands, still no uploads working at webmink shared a post
I did find that in filesystems.php the new permissions section had not been added, so I do wonder if the upgrade completed successfully. I added it manually, made no difference.
I ran the update, did the artisan commands. The artisan media:fix-nonlocal-driver gave me an error. So I still gave uploading pictures a try and nothing had changed.
So I looked at the commit talked about in the github thread and opened up some of the files, but did not see the changes.
I reran the update script but it said update had happened. is it possible the patches aren’t getting applied, which is causing the continued issue?
I had the same !
I did it again, it worked.
You can force it with --force.
I don’t understand why files are not changed. I wonder if it’s because we use a commit number and not a main release.
This is way too strange that multiple people see no change after the upgrade.
I did it again (with -F) and no change unfortunately.
I also get
Warning: fatal: not a git repository (or any of the parent directories): .git
in the middle of the upgrade each time, although the process seems otherwise to complete OK.
That’s something very significant. We need to investigate that… this upgrade seems to fail 
That’s normal and not a problem.
I just saw Pixelfed had a new release (0.11.6), is there a way to test that release and see if that takes? I think you said that this YNH update was only pulling from a commit, so maybe the release will update correctly?
Or, if there are different things you’d like us to try, let us know.
I made the upgrade available for Yunohost this morning 
(before your post actually 
, but that might have taken some time to be reflected in Yunohost catalog).
On my side it doesn’t solve the issue, sadly 
well i am on (0.11.6) still shows No Photo Available
New UI - can upload just says No Photo Available
Old UI - i get oops something went wrong.
I updated and no change with the update. ran the artisan commands just to check. deleted the m folder to get Pixelfed to generate a new one. Even spot checked two files to see if the changes from the previous mentioned commit were there, and they were.
I suspect (as i think you may already) that we have a permissions issue, as I can get it to work with some CHMODing.
I uploaded a new file and the file path is
m/_v2/548602088904634369/c537ce87c-f5971d/6QKPgVfVMjN2/PbghbcO2BwIl6WZJhOHUY7OHmNvuHv1bzYk1NxPT.png
the file permissions as you go through them look like this:
drwx------ 3 pixelfed pixelfed 4096 May 3 18:13 m
drwx------ 3 pixelfed pixelfed 4096 May 3 18:13 _v2
drwx------ 3 pixelfed pixelfed 4096 May 3 18:13 548602088904634369
drwx------ 3 pixelfed pixelfed 4096 May 3 18:13 c537ce87c-f5971d
drwx------ 2 pixelfed pixelfed 4096 May 3 18:14 6QKPgVfVMjN2
-rw-r--r-- 1 pixelfed pixelfed 1010496 May 3 18:14 PbghbcO2BwIl6WZJhOHUY7OHmNvuHv1bzYk1NxPT.png
-rw-r--r-- 1 pixelfed pixelfed 107350 May 3 18:13 PbghbcO2BwIl6WZJhOHUY7OHmNvuHv1bzYk1NxPT_thumb.png
So it looks like the photos are getting the right permissions (0644) but the folder are not (0700 instead of 0755).
IF you CHMOD all those folders back to the m folder to 0755 the image will load and the post works.
HOWEVER.
When you upload a new picture, it also creates a new folder to put them in, and that folder is still being created as 0700. I did double check the filesystems.php file and the permissions part is there with the correct numbers.
not sure if any of that helps…
ah, apologies, just caught up on this issue on github and seems I am where you were already.
I changed my filesystems.php once more. so the PRIVATE folder is 0770. And just like you i get folders that are 0750, and so it still didn’t work.
BUT. I did try something else. I noticed the new files are u:g as pixelfed:pixelfed, but the older ones are pixelfed:www-data
When you CHOWN the folders to pixelfed:www-data, it works even at 0750. Unfortunately, the new folders are still being created as pixelfed:pixelfed
You mean it doesn’t use the settings you wrote in that file ? (just like it does for me)
Nice gotcha !!
I was able to reproduce your fix !
Steps to reproduce:
filesystems.php private folder right to 0750.php8.2 (if you are using latest version 0.11.6, if not php8.1) config:cachephp8.2 (if you are using latest version 0.11.6, if not php8.1) cache:clearchown -R :www-data public/storage/m/_v2/1/someRandomNumber/anotherRandomOne_FolderThanContainsTheNewPicturesSadly images shown from Mastodon as still broken (but opening then in a new tab, hence on Pixelfed, works)?
Hi, I have tried this, but those steps (didn’t try anything else from above as you were still trying to find the error) aren’t enough for my instance. juste installed it yesterday.
Do you want me to open another subject or can we all continue looking for a workaround here ?
Thanks a lot for all the hard work and the help !
Can you share the content of the config/filesystems.php file ?
Hello,
here you are :
<?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('DANGEROUSLY_SET_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' => 0644,
'private' => 0600,
],
'dir' => [
'public' => 0755,
'private' => 0750,
],
],
],
'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'),
],
],
];
hope it helps.
this is correct. file set to 770, result is 750.
Ok, same for me. Thanks
Just to be sure, can you confirm you changed that file content manually ?
This is not the raw content after installation, but the one you changed ? (that’s fine, just making sure )
When you said “aren’t enough”, you mean it is still broken when you upload an image, or that images already uploaded (and fixed with those commands) are still broken ?