Skip to main content

Mixed-Mode Filesystems Still Suck

Problem

Doing an rsync to a filer, the user gets gratuitous errors:

rsync: mkstemp "$LONGPATH/$FILE.gz.FiA0Vm" failed: Operation not permitted (1)

Solution

OK, that was painful.

The root problem here is that this is a mixed-mode filesystem. In a mixed-mode filesystem, the filer tries to keep both unix access permissions and windows ACLs present and functional on files/directories. The problem is that it tries to be secure by default – in that if it can’t figure out what the mishmash of potentially contradictory information is, the default is to deny permission.

The contributing problem to this issue is that there is no plan for ACL management. Access to files and directories is granted on a user-by-user basis, mostly implicitly (in that permissions are inherited from higher up in the tree) but at excitingly random locations, explicitly (which break the implicit inheritances).

When the filer hits situations like this, the unix permissions you see are not necessarily what you get – the text book example of this are files which are root:root 777 that nobody can manipulate, but this time I got to see some 000 files and directories too.

To solve this problem (and this kind of problem) will require probably a reorganization and reclassification of the data, creation and user management of appropriate groups, a commitment to both keeping them up-to-date, and resisting the urge to slap permissions on this one object to “fix just this one problem”. Forcing file systems to be Windows-style or Unix-style too wouldn’t hurt either – or at the very least forcing them into separate trees, even if they are joined together at the same share level. Mixed-mode filesystems are hell.

That’s a larger problem for other minds, probably to be addressed after the migration away from the $ZONE AD zone happens.

(See also Mixed Mode Filesystems Suck.)

More immediately.

I have ended up doing the following:

  • Changing the windows ACLs on the Fault_diag directory to be $USER/$USERGROUP/Administrators all == Full Control, and forced inheritance of those ACLs down the Fault_diag tree directories and files
  • Changing the unix ownerships to be $USER:$GROUP, 600 or 700 (files or directories as appropriate), an action which almost certainly whacked all the ALCs I carefully applied in the previous step Anyways, after doing both those things, the rsync command works again for $USER.
Back to top