Excellent post. Thanks for taking the time for such a thoughtful reply. For those reading along or for my own purposes of tracking thoughts for a case study o

Excellent post. Thanks for taking the time for such a thoughtful reply. For those reading along or for my own purposes of tracking thoughts for a case study of this experience, I'll add some comments: > Drive isn't (at least yet) designed with a central group share in mind. Trouble is Google advertise it as being suited for this. Google provides well written docs to guide you through setting up a central file share for your organization. I just looked for the doc again. Its been moved/removed in the last few weeks. Now I see they have a new/improved feature called Team Drive which may solve some aspects of my troubles. > Especially if they use one of those insane massive shares that the whole company has write access to. Google advertises a 10 terabyte drive for $99 a month. The Business and Education plans advertise unlimited storage. This combined with a wealth of other docs Google provides for using G Suite for Business may lead a reasonable person to conclude it could handle a measly 1.5 terabyte drive account. > Drive API: I may be misunderstanding your use case, but I think this is just as simple as logging in as the records user and authorizing the application instead of granting it global scope to the GSuite account. Yeah, that's the next step for us to write some code against. Google Drive's API docs tell you that for server-to-server API usage, use the service account method. This method gives access (for a given scope) to all accounts. I've found no docs or example code for server to server API using the client/server OAuth method which would restrict access to a single account. rclone uses the client/server OAuth method. Its tricky stuff. To do this on a server we need to write a process so a server admin can manually bootstrap the OAuth access and cache the access tokens for reuse by the server. This method requires a bit of tricky work to refresh the server's access with a refresh token at times. No docs on how long this access is good for or how often you can refresh. So to do this for long running server access, we would need some method so the server can email me when the token expires so I can manually bootstrap the OAuth again. > records@mydomain makes me think you're using a file sharing system for something that would be better served by purpose built software. Sure. My use case wan't clear in my original post. The reason I picked this approach is Google Docs is great for our needs. Having the student's work evidence embedded in a shared drive (in read only folders) alongside other folders containing Google Docs of teachers assessment, feedback and admin docs is pretty slick. Actually this stuff is working great. Its the ops/admin aspects that aren't ready for business. > Sync client: If bandwidth is constrained roll out the client to users in comfortably small increments. When I checked about a month again, my only option as an admin was on for all users or off for all users. Hard to manage a roll out plan when Google pushes their sync tool on users and I can't control access on a per account basis. For now, its off. I'm happy to leave it that way ;)