On Thu, Feb 10, 2011 at 8:06 AM, sf...@users.sourceforge.net wrote:
find /srv/wine/wine-Diablo_II -type d -exec chmod ugo+rwX '{}' \;
find /srv/wine/wine-Diablo_II -type f -exec chmod ugo+rwX '{}' \;
I'd suggest you to do it carefully.
- giving unnecessary permission bits can be a problem
Jeff Hanson:
With the chmod permission changes the chown is not necessary. The ro
branch files in the squashfs are owned by wineadmin. The permissions
are not a problem since the squashfs is a ro loop mount. Any writes
will be to the aufs rw branch that the user owns.
If you have very
Jeff Hanson:
The aufs mount point. That is what the users will be working with.
Do you mean only the directory?
If so, aufs does copyup the dir only, and I don't think it fills up the
rw branch.
Some is the problem. I can't predict which files out of the ro
:::
Right. How many
On Tue February 8 2011, Jeff Hanson wrote:
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 -
Michael S. Zick:
For that use case, jro's suggestion of a custom, fuse based, file system la=
yer
that translates the current-user-specfic section of the master file's ACLs
into current-user permissions may be what you need.
As a WAFG, I suspect it would not be a trivial file system to
On Wed, Feb 9, 2011 at 3:34 AM, sf...@users.sourceforge.net wrote:
Jeff Hanson:
The aufs mount point. That is what the users will be working with.
Do you mean only the directory?
If so, aufs does copyup the dir only, and I don't think it fills up the
rw branch.
mount -v -t aufs -o
Jeff Hanson:
chown -R administrator:administrator /home/administrator/.wine-Diablo_II
Because you add -R, chown handles all of the specified dir, the files
and the sub-dirs under it recursively and unconditionally. But what I
suggested is to chown only the file which a user is going to modify.
On Wed, Feb 9, 2011 at 8:38 PM, sf...@users.sourceforge.net wrote:
Jeff Hanson:
chown -R administrator:administrator /home/administrator/.wine-Diablo_II
Because you add -R, chown handles all of the specified dir, the files
and the sub-dirs under it recursively and unconditionally. But what
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
Jeff Hanson:
Users can't run chown because they are not root.
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.
Hello Jeff,
Jeff Hanson:
point. From reading through the man page and the following posting,
it appears that AUFS doesn't support setting the mount point UID/GID
independently of the branches:
https://sourceforge.net/mailarchive/message.php?msg_id=21772475
Is there any plan to add UID/GID
On Fri, Feb 4, 2011 at 8:56 AM, sf...@users.sourceforge.net wrote:
While I think it may be possible to implement such feature in aure, aufs
should not do it. Because it is a different kind of feature. I think it
is better to wrap the ro branch by fuse or cifs as you are doing.
If I were you,
18 matches
Mail list logo
