> ## Documentation Index > Fetch the complete documentation index at: https://docs.1archive.io/llms.txt > Use this file to discover all available pages before exploring further. # Source Permissions > How access to a Source or folder works. Sharing passes down through nested folders, and recipients can walk the folders leading to their share, but never see anything off to the side. A **Source** is a hard drive that 1Archive has read into your catalog. Sources live inside folders, and folders can sit inside other folders. For sharing, folders and Sources work the same way. Both can be shared, and a share on a folder passes down to everything inside it. Your **organization role** is account-wide; it sets how far your access can ever go. What this page covers is the **second layer**: **Can Edit** and **Can View** on each folder or Source (who you've added, **visible to the whole org**, and how those choices pass down the tree). See [Roles & Permissions](/team/roles-permissions) for Owner, Admin, Editor, and Viewer at the org level. Diagram showing Sources as a walled inner circle, Collections in the middle layer accessible to org members and collaborators, and the Public reachable via shareable link. Diagram showing Sources as a walled inner circle, Collections in the middle layer accessible to org members and collaborators, and the Public reachable via shareable link. ## The two ways to share a Source or folder Pick whichever fits the material: * **Make it visible to the whole org.** Every person in your organization can see it. This is the right call for anything not sensitive: reference material, public-facing work, stock libraries. * **Add specific people to it.** You pick who's on the list and what they can do (Can Edit or Can View). This is the right call for client work, unfinished pieces, or anything that shouldn't be seen by the full team. Either way, the share covers the item you pick *and* everything nested inside it. Add Peter to the `Marketing` folder with Can Edit, and Peter gets Can Edit on every folder and every Source inside `Marketing`. No extra clicks. ## When a folder and the Sources inside it disagree Every folder and Source is set one of two ways: visible to the whole org, or limited to specific people. Nest them and two rules decide who can see what. **The more private setting wins as you go down.** Limit a folder to specific people and everything inside rides along, even a Source someone set to visible to the whole org. Lock the `Severance Package` folder and every Source in it is locked too. It runs the other way as well: a folder that's visible to the whole org never pries open a Source inside it that you've limited to specific people. That Source stays on its own list. **Adding people still reaches all the way in.** Put someone on a folder's list and they get everything inside it, including the Sources you've kept private. That's how you hand a team a locked folder: limit the folder, add the team, done. You never touch the Sources one by one. So a locked folder is a real wall. Nothing leaks out because a folder above it is open, and nothing slips in because a Source inside it was left open. The only way in is to be on the list, or on the list of a folder that holds it. ## What the two share roles let you do | Role | What it lets someone do | | ------------ | --------------------------------------------------------------------------------------------------- | | **Can Edit** | See and open the files, and also add, move, rename, or delete folders and Sources inside the share. | | **Can View** | See and open the files. No changes to the folder structure or the Sources themselves. | A person's role on a Source is set by the highest share they have anywhere above it. If you're added to the `Marketing` folder as Can View and then added to one Source inside it as Can Edit, you have Can Edit on that one Source and Can View on the rest. ## What a share actually looks like to the recipient This is the part that trips people up, so it's worth spelling out: when you share a Source that lives a few folders deep, the person you've shared it with sees the **folders on the way to it**, but nothing else. * They can walk through the folders leading down to their share, like a breadcrumb trail. * They can't see any sibling folders or Sources along the way. * They can't read the contents of those breadcrumb folders. Only the names show, so they have a way in. This means you can share a single Source buried six folders deep without accidentally showing the person everything else those folders hold. Every scenario below walks through a version of this. ### Scenario 1: a single Source shared deep in the tree The full catalog: ``` /Clients /Initech /1999 TPS Reports /Discovery ← Peter gets Can View /Y2K Recovery Plan ← Peter was not added /Initrode ← Peter was not added ``` What Peter sees when he opens 1Archive: ``` /Clients /Initech /1999 TPS Reports /Discovery ← he can open the files here ``` Peter can walk from `Clients` down to `Discovery`, but the breadcrumb folders stay closed. No file list inside `Clients`, `Initech`, or `1999 TPS Reports`. He has no idea that `Y2K Recovery Plan` and `Initrode` exist. ### Scenario 2: a whole folder shared Sometimes it's easier to share a whole folder than pick Sources one by one. Drop a person on a folder, and the share covers every Source and sub-folder inside it, now and in the future. The full catalog: ``` /Projects /TPS Portal Redesign ← Michael gets Can Edit /Design Explorations /Engineering Handoff /QA Screen Caps /Launch Checklist /Legacy Intranet Archive /Intern Orientation 1999 ``` What Michael sees: ``` /Projects /TPS Portal Redesign ← he can edit anything inside /Design Explorations /Engineering Handoff /QA Screen Caps /Launch Checklist ``` Michael can work inside the whole `TPS Portal Redesign` folder. He can add new Sources to it, rename the sub-folders, and move files around. He still doesn't see `Legacy Intranet Archive` or `Intern Orientation 1999`. Those were never shared. If you're going to share lots of Sources with the same person over time, put them in a folder and share the folder. Any new Sources dropped into that folder later are automatically covered. ### Scenario 3: two shares that overlap When someone has more than one share that covers the same Source, the **highest role wins**. 1Archive never quietly lowers access. The full catalog: ``` /Clients /Initech ← Joanna gets Can View on the whole folder /1999 TPS Reports /Discovery ← Joanna also gets Can Edit on this one folder /Exhibits /Y2K Recovery Plan ``` What Joanna sees: ``` /Clients /Initech ← read-only here /1999 TPS Reports ← read-only here /Discovery ← she can edit /Exhibits ← read-only here /Y2K Recovery Plan ← read-only here ``` Joanna can open every Source under `Initech`, because the folder share gives her Can View on all of them. Inside `Discovery`, she also has Can Edit because of the direct share, which outranks the folder-wide Can View, so Can Edit is what applies there. Anywhere outside `Discovery` but still under `Initech`, she's read-only. ## Who can change the catalog structure Moves, renames, and deletes touch the folder tree, so they're tied to write access: * **Adding, moving, renaming, or deleting** a folder or a Source needs **Can Edit** on it. * **Making a new top-level folder** (one that sits at the root, not inside any other folder) is limited to Owners, Admins, and Editors in the org. Deleting a folder removes every Source inside it from the catalog. 1Archive will ask you to confirm, but there's no undo. When in doubt, move the folder into an archive folder instead.