3 ms·

Drive isn't (at least yet) designed with a central group share in mind. Anyone coming from an SMB share on a local server of course finds it mind boggling. Espe

Drive isn't (at least yet) designed with a central group share in mind. Anyone coming from an SMB share on a local server of course finds it mind boggling. Especially if they use one of those insane massive shares that the whole company has write access to. SMB shares are a command and control system and Drive is an organic user-to-user collaborative system. So you're going against the grain right off the bat. Which isn't to say I think your use case is unreasonable or that I disagree with your assessment. But regardless of right or wrong straying from the golden path with SaaS is dangerous. With any software really, but SaaS is by far the most precarious. If it's not designed with your use case in mind it's not uncommon to run into bugs or deprecations. My not-so-practical advice: My first suggestion would be to evaluate if you really need that command and control or if it's something you're used to having. Once you let go of that dealing with Drive as an administrator becomes dramatically easier. The worst thing you have to deal with is recovering deleted data (available for 25 days) and complaints about the Windows/macOS clients which most people end up ditching as they realize the golden path there is the web interface. Obviously this depends a lot on management style and culture. Sometimes letting go is so hard that it hurts more than it helps even if you commit to it. My second suggestion would be to evaluate if you're using the right tool for the job. fileshare@mydomain seems obvious but records@mydomain makes me think you're using a file sharing system for something that would be better served by purpose built software. Like a CRM or a document management system. Even an SMB share is a terrifying place to store structured data built around human processes that require them to follow rules and not delete things (even at small scales). More practical: Sync client: If bandwidth is constrained roll out the client to users in comfortably small increments. 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. Here you're going against the grain in a couple different ways: That kind of access is meant for things like an interview scheduling system that needs read access to all calendars. The expectation is that apps that need access to a single account would simply get that access by asking the user for it. Backups: Besides using the sync client and taking snapshot based backups from the local copy (which is a half-assed fragile hack) the only thing that makes sense is trusting Google. That's only fair to ask of you if we're not talking about data that would sink your business if lost. But if all of the data is that critical are you using the right tool for the job? Even a local SMB server setup would need to be carefully designed to account for the myriad ways you can lose data. If it's only a subset do you need to back it all up? Maybe what you really need to backup is a manageable subset. Good luck. I hope you get this sorted out–it sounds like a huge headache.

jhancock 10y ago
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 ;)

jhancock 10y ago

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 ;)