2011-05-26 03:18 PM
I'm running 8.0.1RC1. Currently after creating a volume and mounting it on linux via NFSv3, its root directory is owned by 0:0 (root) and is by default not writeable by anybody. All my qtree volume permissions are set to 'unix'.
I would like to know how to change the Default User ownership of a volume. This can be either name-based or UID/GID.
I am looking for something similar to this:
options wafl.default_qtree_mode 0750
Except for root folder ownership rather than bitmask permissions.
I am not interested in mapping every single nfs user to a specific UID/GUID (anon/maps), nor am I interested in granting every box root access to a volume. I would simply like to mount a newly created volume and have its default root folder ownership be, for example, 1234:1234.
Does anyone know how I would go about this?
2011-05-27 03:35 PM
I suspect my solution may have something to do with qtree's; however, as stated above wafl.default_qtree_mode deals with bitmask permissions (read, write, execute for owner/group/other) and not file/folder ownership/group. I'd rather not set 0777 on a volume as then any user would be able to write to it.
2011-06-10 03:52 PM
Just export the filesystems with 'anon=0". Then everyone is root. It is going to be a complete mess, but it will be very easy to setup. I guess security and authentication mechanisms are unknown where you are.
Otherwise, just export the volume to an admin machine where you set the rights (+sticky bits) on the underlying qtree and then export the qtree to your lusers.
2011-06-17 11:51 AM
I specifically said I didn't want root for everyone. We already do the admin machine mount+perm change method, and it's already scripted where necessary.
90% of vol creation requests are going to end up being written to by a specific UID/GUID. I want to skip having to mount the vol on an admin box to change permissions every time.
2011-06-17 03:26 PM
No, you said you didn't want to grant every box root permissions... By exporting the volumes 'anon=0' you just make everyone root... There is a bit of a difference...
I know of no other way of dealing with filesystem permissions than from remote systems. You are probably going to have to accept the fact that some server that has "root" mount rights will need to be used to setup rights for the filesystem for others. The situation is the same for CIFS filesystems.
EoD from me.