Daniel Reichelt wrote:
Hi list,
I have an unionfs mount setup like this:
# mkdir br1 br2 rwunion
# mount -t nfs -o ro server:/nfsexport /br2
# mount -t unionfs -o dirs=/br1=rw:/br2=ro none /rwunion/
So far so good. When I try to add new files or remove files that pre-existed on
the ro-nfs branch, that works just fine. However appending/chaning files
originating from the ro-nfs branch, I get this:
# ls -la /br1
# ls -la /br2
-rw-r--r-- 1 root root 55 2008-11-06 04:41 test
# ls -la /rwunion
-rw-r--r-- 1 root root 55 2008-11-06 04:41 test
# echo >test
bash: test: Permission denied
This is matches my expirence as well. Quite annoying sometimes... :)
F.e., on a unionfs-root with one branch from read-only nfs and
another on tmpfs:
# apt-get update
apt: unable to open /var/lib/apt/lists/lock: Permission denied
# touch /var/lib/apt/lists/lock
# apt-get udpate
.. apt goes on successfully ..
I.e., when opening a file residing on a read-only branch for
writing, unionfs returns EACCES, but touch'ing etc that file
makes a copy in a read-write branch, and opening THAT file
works. So looks like the open(O_WRITE) case when the file
is on the ro branch does not work as expected.
But after thinking about this for a bit... the COW (Copy On Write)
should really be coW, not coO (copy on open). IMHO. I.e., to
let open(O_WRITE) to succeed, but to create the copy on first
real write, not on open. Oh well.
By the way, is it 2.6.27-specific (the kernel) or 2.5-specific
(unionfs release)?
Thanks!
/mjt
_______________________________________________
unionfs mailing list: http://unionfs.filesystems.org/
unionfs@mail.fsl.cs.sunysb.edu
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
