Gem sharing stops in three places: the order I check when a shared Gem never shows up

I had packaged a client's site maintenance steps into a Gem and was about to hand it over to their coordinator. I reached for the share icon and it simply was not there.

My first thought was that my own account was too limited. I have no access to that organization's Admin console, so I assumed the next move was to ask their IT team and wait.

The cause sat much earlier in the chain. I had attached one file to the Gem's knowledge section in a format that cannot be shared at all.

Decide where the block is before you ask anyone about it. Since I started working that way, my messages to IT teams tend to end in one round trip instead of four.

Gem sharing stops in three places: the Gem itself, the Admin console, and Drive. Which one it is decides who is able to fix it.

If the share icon is missing, there are only two reasons

For work and school accounts, the Gemini app help page lists exactly two reasons the share icon does not appear.

A Gem with attachments can be shared only when those attachments came from your device or from Google Drive. Anything else in the knowledge section blocks sharing for the whole Gem. NotebookLM notebooks also cannot be used as a source for a shared Gem.

The useful part is that a missing icon does not automatically mean an admin setting. Open the knowledge section first and look at where each attached file came from. As an indie developer I skipped that step and went straight to asking someone else, so I now keep it written down as step one.

Turning the Admin console setting off does not undo past sharing

There is one switch on the admin side. In the Admin console, go to Menu, then Generative AI, then Gemini app, scroll to Gem sharing, and set Allow users to share Gems. The Gemini settings administrator privilege is required.

That switch governs both whether people in the organization can share Gems and whether they can use Gems shared with them.

The Workspace admin help page carries a caveat that is easy to read past. Even with the setting off, Gems that were already shared stay accessible and shareable from within Drive.

So the switch is a tap for future sharing, not a plug for water that has already flowed. If you are trying to contain information and you only look at the Admin console, you end up believing something stopped when it did not.

That is where I redrew my own line. The Admin console decides how much goes out from now on; Drive is where you count what already went out. My first mistake was trying to solve two different jobs on one screen.

When the setting is right but nothing changes, suspect groups and propagation

Two things explain almost every "I changed it and one person still cannot share" report.

The first is scope. The setting can be applied per organizational unit or per configuration group, and group settings override organizational units. You can enable it on a department's OU and still lose to a configuration group that has it off.

The second is time. Changes can take up to 24 hours to propagate, though they usually land sooner. The reasoning "I changed it, I tested it immediately, it is still broken, therefore my change is wrong" doubles back on itself right here.

I wrote about separating rollout waits from real faults in Telling a Workspace rollout wait apart from an actual fault. The same habit carries over to Gem sharing without modification.

A shared Gem lives in Drive

A shared Gem is saved into a new folder in Google Drive, and the files attached to it land in that folder too.

That is the third place. Your Drive sharing settings apply to Gems as they are. If your organization allows documents to be shared externally, Gems can go external as well. If external sharing is closed, no Gem escapes it either. There is no separate external-sharing policy that belongs to Gems alone.

There is one more consequence worth knowing: remove a person's access to a Gem and that Gem disappears from their Drive.

Who can reach a Gem today is countable from the Drive side. I keep a small audit function in the Apps Script project I use for my own work.

/**
 * Opens the Drive folder holding your shared Gems and logs, per file,
 * the general access level plus editors and viewers.
 * Before running, open [Gems] → [More] → [Find in Drive] in the Gemini app
 * and put the real folder name into FOLDER_NAME.
 */
function auditSharedGemAccess() {
  const FOLDER_NAME = 'Gems'; // the name differs between accounts
  const folders = DriveApp.getFoldersByName(FOLDER_NAME);
 
  if (!folders.hasNext()) {
    Logger.log('Folder not found: %s', FOLDER_NAME);
    return;
  }
 
  const files = folders.next().getFiles();
  let checked = 0;
 
  while (files.hasNext()) {
    const file = files.next();
    try {
      const editors = file.getEditors().map(function (u) { return u.getEmail(); });
      const viewers = file.getViewers().map(function (u) { return u.getEmail(); });
      Logger.log(
        '%s | access=%s | editors=%s | viewers=%s',
        file.getName(),
        file.getSharingAccess(),
        editors.join(', ') || '(none)',
        viewers.join(', ') || '(none)'
      );
      checked++;
    } catch (e) {
      // Permission lists are unavailable for files you do not own
      Logger.log('%s | could not read permissions (%s)', file.getName(), e.message);
    }
  }
 
  Logger.log('Files checked: %s', checked);
}

Running it produces lines like these.

Site maintenance Gem | access=PRIVATE | editors=(none) | viewers=staff@example.com
Old intake check Gem | access=DOMAIN_WITH_LINK | editors=(none) | viewers=(none)
Files checked: 2

The try block matters more than it looks. Permission lists are not readable for files you do not own, and without it the first such file ends the run, leaving the rest of your Gems uncounted. One failure should not end the inventory.

getSharingAccess() returns PRIVATE, DOMAIN, DOMAIN_WITH_LINK, ANYONE, or ANYONE_WITH_LINK. The second line above is the case worth catching: a Gem still open to anyone in the domain who has the link. For what you can do from the Drive side before revoking anything, I covered that in Limiting what Gemini reads from Drive without unsharing.

When the Gem opens but the answers differ, the files were shared separately

Access to a Gem and access to the files inside it travel separately. That is the prompt asking whether you also want to share access to the files, with viewer, commenter, or editor to choose from.

Skip it and the other person opens the Gem perfectly well while the knowledge files stay unreadable to them. Same instructions, different answers on their screen and yours. It surfaces not as "sharing failed" but as "sharing worked and the results disagree", which takes considerably longer to trace.

In the other direction, anyone you grant editor access can rewrite the custom instructions and replace the attached files. Rewrite those and the answers change too. What you hand over is a role, not a frozen output.

If you only need temporary access, you can set an expiry date and time per recipient. For outside collaborators I would rather use that than rely on remembering to clean up later.

The order I check

Pick one Gem you have already shared and open [Gems] → [More] → [Find in Drive] today. Seeing where your own Gems actually sit in Drive once means that the next time someone tells you they cannot open one, you will not have to guess which screen to open first.