Clarification Needed on Moving Files Between Buckets in Supabase Storage

[omaerkhan]

Hello!

I am trying to move files from one bucket to another using the Supabase Storage API. I referred to the documentation here: https://supabase.com/docs/reference/javascript/storage-from-move

The documentation states: "Moves an existing file to a new path in the same bucket."
However, there is an optional parameter ⁠options with a key ⁠destinationBucket, described as "The destination options."
This suggests that moving files between different buckets might be supported or planned. However, I encountered errors when attempting this functionality with the ⁠destinationBucket parameter.

Example Code:

const { data, error } = await supabase
  .storage
  .from('temp')
  .move('user/timestamp/file.png', 'user/id/file.png', { destinationBucket: 'users' });

Issue:

I'm receiving an ⁠Object not found error, even though the file exists in the source bucket.

Questions:

1. If the move function is intended to work within the same bucket, why is there a ⁠destinationBucket parameter? Does this parameter enable cross-bucket moves, or is there a misunderstanding in its usage? Is the documentation accurate?

2. If cross-bucket moves are not supported, the alternative involves downloading files to a server and re-uploading them to a different bucket, which seems inefficient. Is there a more efficient method to transfer files between buckets without the need for downloading and re-uploading?

Thank you for your assistance!

[GaryAustin1]

It is supported according to the docs.
https://supabase.com/docs/guides/storage/management/copy-move-objects#move-objects

Maybe an RLS issue?

[omaerkhan]

Thank you for your continued patience.
Can you please clarify: can something other than a service role client successfully run the supabase.auth.admin.listUsers() function?

I created this function as a litmus test to check that it's a service role based client (and to my understanding, RLS should be bypassed):

async function TestIsServiceRole(supabase: SupabaseClient, prefix: string, suffix: string = '') {
  let isServiceRole: boolean;
  let noOfUsers: number = -1;
  try {
    const { data, error } = await supabase.auth.admin.listUsers();
    if (error) throw error;
    noOfUsers = data.users.length;
    isServiceRole = noOfUsers > 0;
  } catch {
    isServiceRole = false;
  }
  console.log(
    `${prefix}: ${isServiceRole ? `Service Role Client (${noOfUsers} users)` : 'Anon Client'} ${suffix}`,
  );
}

As per this, the client is a service role based client (as it should be )
And yet without the proper RLS settings, when I try to Move the files, the above-mentioned Object Not Found error comes.

[GaryAustin1]

Can you see your network calls?
Can you test on a hosted instance where the log shows you the role coming in?

Yes listUsers requires service_role in the Authorization header.

But unless you modified service_role to obey RLS in your Postgres (which can't be done on hosted and I ASSUME can't be done on local) then it will NEVER obey RLS. It is not a Supabase thing, but a Postgres thing that a role with bypass RLS will always ignore. You can check the role status in in Database/Roles tab.

Also, you are running your "test" list code in the exact same spot as the other call?

[omaerkhan]

I did spend a lot of time trying to see network calls locally (tried a few proxy software like Charles Proxy and Proxyman, and several configuration settings - but wasn't able to get my Supabase calls to show up in any of them)

I have not modified the service role (or really anything major in Supabase / Postgres - I do a supabase db reset quite often and my migrations are quite ordinary).

Yes I ran the TestIsServiceRole function several times throughout the file including immediately before the call to Move the files in storage - they all show the client as a service client.

The only thing that just occurred to me is that because I'm creating a new user, perhaps that new-user sign-up is somehow affecting my supabase client and causing it to behave with that user's role even though it's set up with the service key... (it's a random guess so I'll check for it when I'm back at my computer shortly).

My dev workflow isn't set up for testing on a hosted supabase instance so I've been avoiding it, but I will do that next as well and get back to you with more info.

[GaryAustin1]

If you did not use admin.createUser, but something like signUp to create the user in that client then the client would become that user.

[omaerkhan]

That was it - I was using signUp because the createUser doesn't send an email confirmation, and inviteByEmail doesn't allow setting the password...

For now I created a separate supabase client and used that to signup so the original client isn't affected.

I couldn't find anything in the SignUp function docs to indicate that the supabase client would take on the role... I'm guessing I missed something, but if you think it's helpful, perhaps this should be added to the docs?

Thank you once again.