Private files, distributed colleagues
An office file server. A team working in different places.
A design team keeps project files on office storage. Some colleagues work remotely; a contractor needs one project folder. The requirement is a private path to that storage, with file permissions and application credentials still controlled by its owner.
A separately enrolled device with the required network grant.
An approved destination route and verified return path.
Its own accounts, folder permissions and security updates.
A supported storage host may instead enroll directly. Gateway access does not install an agent on the NAS.
Conceptual planning example · Storage protocols, devices and gateway support require deployment-specific verification.
Resource plan
Separate the network grant from the folder permission.
- Storage owner
- Maintains the NAS or file server, user accounts, folder permissions, updates and independent backups.
- Network owner
- Approves the destination and operates the gateway or enrolled storage host. Resolves route overlaps and local firewall rules.
- Employee
- Uses an approved computer and the storage application’s own credentials. Network membership alone does not grant every file share.
- Contractor
- Receives a limited network grant and a separately scoped project account. Both need review when the engagement ends.
A phone or tablet may use a compatible application to reach the resource on a supported platform. Desktop file sharing and mobile file applications have different protocol and background constraints; test the actual workflow rather than assuming identical behaviour.
What the network provides
A route to the files. The storage service still does the rest.
Networks provides the intended private reachability model. File locking, synchronisation, offline copies, version history and backup recovery belong to the storage application. A connection to the NAS does not create a backup or a file-sync service.
Large files and chatty protocols may behave differently across a wide-area connection. Evaluate the real files, access latency and bandwidth. The design does not promise local-LAN performance.
Use supported private naming or an explicit resource address. Local broadcast-based discovery may not cross a routed boundary. Avoid making SMB or a storage administration interface public just to make discovery easier.
A supported gateway can provide an approved path without a native client on every storage device. This does not make all NAS vendors compatible or give each downstream device a Fibmesh endpoint identity.
A useful first evaluation
Three results worth recording.
- The actual file workflow
Test opening, editing and saving a representative file with the approved user. Verify the storage application’s permissions and expected behaviour after an interruption.
- The restricted account
Confirm that the contractor can reach only the approved resource and can read or change only the permitted project data.
- End of access
Remove the network grant, revoke a retired enrollment where appropriate, and retire the storage account separately. Existing local copies are not erased by network revocation.
Keep an independent local recovery route for the storage administrator. Review release, platform and gateway support before using this plan for business-critical files.
Explore Fibmesh Networks →Plan project-scoped access →