On Fri, Feb 4, 2011 at 4:03 PM, Jeff Hanson jhanso...@gmail.com wrote:
Users can't run chown because they are not root.
Another problem is that the CIFS mounts show up in Gnome/Nautilus as
mounted volumes. Since these are ro mounts that only exist for the
UID change they aren't useful to the
On Sun, Feb 6, 2011 at 9:58 PM, sf...@users.sourceforge.net wrote:
How about writing a wrapper?
Allow chown after some tests.
- the target path is aufs, or /home/$USER in your case?
- the target uid is $USER
- etc
The warpper may be implemented suid-ed, or customized /etc/sudoers.
I can
On Tue, Feb 8, 2011 at 2:44 AM, sf...@users.sourceforge.net wrote:
Users have their own rw branch individually, don't they?
chwon makes the file copied-up in aufs. So it never affect other users.
Tried that. The result is that the rw branch ends up with the entire
data of the ro branch. It
On Tue February 8 2011, Jeff Hanson wrote:
On Tue, Feb 8, 2011 at 2:44 AM, sf...@users.sourceforge.net wrote:
Users have their own rw branch individually, don't they?
chwon makes the file copied-up in aufs. So it never affect other users.
Tried that. The result is that the rw branch
On Tue, Feb 8, 2011 at 3:59 PM, Michael S. Zick a...@morethan.org wrote:
That is a property of inode file systems - only one location for ownership.
Symbolic link chain at the directory name level -
Hard links are many names-to-single inode - with one location for ownership.
There are file
Jeff Hanson:
Tried that. $BB (BThe result is that the rw branch ends up with the entire
data of the ro branch. $BB (BIt seems that aufs copies the entire file to
the rw branch even if only the ownership changes. $BB (BEffectively:
aufs + chown = cp
which eliminates my primary reason
On Tue, Feb 8, 2011 at 10:34 PM, sf...@users.sourceforge.net wrote:
What did you chown?
The aufs mount point. That is what the users will be working with.
They could access the rw branch directly since it is in their home but
that is unlikely since it is hidden.
My asummption is
- you have
