Hello everyone,
to prevent security issues, I upgraded to a more recent kernel. It's
2.6.31.6 - without any patches from kernel.org. Since I'm using that kernel
with openafs 1.4.11 (actually it's Russ Allbery's Debian package, version
1.4.11+dfsg-5), my kernel prints out lots of lines like this:
Hi,
one of our users encountered a really strange problem: a specific file
could not be deleted
from windows. No problem to copy or move the file, but delete or
writing to the file do not work.
Note that copies of the file can be deleted, but not the file itself.
Also, no problem to do
Any hints? The file can be provided on request (contains private data).
Wild güess: Äre there åny characters in the file name öther than ASCII involved?
Harald.
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
Anders Magnusson wrote:
Hi,
one of our users encountered a really strange problem: a specific file
could not be deleted
from windows. No problem to copy or move the file, but delete or
writing to the file do not work.
Note that copies of the file can be deleted, but not the file itself.
Harald Barth wrote:
Any hints? The file can be provided on request (contains private data).
Wild güess: Äre there åny characters in the file name öther than ASCII
involved?
Harald.
Ever since 1.5.50 the Windows client treats reports all file names as
Unicode. If the name cannot be
John W. Sopko Jr. wrote:
We have installed OpenAFS for Windows 1.5.66 on 2 Windows XP SP3
machines and cannot get \\afs\cell_name UNC paths to work.
We have many older 1.5.55 clients using both kfw and kaserver
authentication and the UNC paths work. We have been moving off
drive letters to
Jeffrey Altman wrote:
Anders Magnusson wrote:
Hi,
one of our users encountered a really strange problem: a specific file
could not be deleted
from windows. No problem to copy or move the file, but delete or
writing to the file do not work.
Note that copies of the file can be deleted, but
On Mon, Nov 23, 2009 at 3:52 AM, Frank Burkhardt f...@gmx.net wrote:
Hello everyone,
to prevent security issues, I upgraded to a more recent kernel. It's
2.6.31.6 - without any patches from kernel.org. Since I'm using that kernel
with openafs 1.4.11 (actually it's Russ Allbery's Debian
On 23 Nov 2009, at 08:52, Frank Burkhardt wrote:
Does anyone know, what it means?
It means that we're not informing the IMA audit layer when we open a
disk cache file for writing. Unfortunately for us, the kernel is
telling it when that file gets closed, and so you get an imbalance
Anders Magnusson wrote:
Thanks, this was the problem, except from that the read-only attribute
in properties were not shown as set. If the file mode is:
-r--rwx---
then the file cannot be deleted but the read-only attribute is not shown
as set either.
This will be fixed in the next release.
On 23 Nov 2009, at 14:25, Marc Dionne wrote:
I don't think IMA is enabled on your typical distro kernel, so the
combination of AFS and IMA probably has had very little testing. Is
it intentional that you have it enabled in your kernel .config?
Sadly, from a look at the Fedora CVS, it seems
On Mon, Nov 23, 2009 at 12:49 PM, Simon Wilkinson s...@inf.ed.ac.uk wrote:
Sadly, from a look at the Fedora CVS, it seems like Fedora 12 is shipping
with IMA enabled.
Yeah I saw the log of the discussion on jabber. Ick. Seems odd and
error-prone that dentry_open would not be symmetric with
Jeffrey Altman wrote, On 11/23/2009 8:47 AM:
John W. Sopko Jr. wrote:
We have installed OpenAFS for Windows 1.5.66 on 2 Windows XP SP3
machines and cannot get \\afs\cell_name UNC paths to work.
We have many older 1.5.55 clients using both kfw and kaserver
authentication and the UNC paths
John W. Sopko Jr. wrote:
Why is it a bug? Is the plan to eventually use the SRV record
in place of the AFSDB record for clients?
If the site relies on AFSDB records, either
stick with 1.5.65 or add the new DNS SRV records for
_afs3-vlserver._udp.cellname IN SRV 0 0 7003
We added the
14 matches
Mail list logo
