As probably many others, I work in an environment where Windows servers
(and thus CIFS filesystem) is used to store home data and backuped
shared data. With OpenOffice 2.0 now out, reading and writing Microsoft
Office documents is generally not anymore a problem except due to
current CIFS bugs.
I tried to do my part of bug hunting, carefully reporting bugs and
offering help to try to fix them (although I cannot do too hazardous
testing on my professional Laptop. See bugzilla reference below).
Unfortunately, things did not improve over the past 5 months and even
recently slightly got worse (see second bug).
Trying to push Linux in corporate environments in such condition is very
difficult because, due to those bugs, you cannot:
1) save a new openoffice document twice,
2) create mail folders from inside thunderbird (local mailbox shared
with windows),
3) avoid to do FSCK after each reboot,
I've seen many changes going in CIFS git tree during this period but
only few bugs got really hunted and fixed (try to set the close option
in bugzilla at
<https://bugzilla.samba.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=CifsVFS&content=>).
SMBfs do not exibit some of the bugs CIFS has but has other limitations
as well.
Could other on the LKML list try to reproduce/confirm the following bugs
with the latest snapshot:
NB : the second bug appeared with CIFS 1.39 and is not present in 2.6.14.2
BUGS :
<https://bugzilla.samba.org/show_bug.cgi?id=2673>
<https://bugzilla.samba.org/show_bug.cgi?id=3237>
May I suggest to fix bugs as a priority before adding new features for a
while? Or at least make sure enough testing is done to avoid regressions?
-- eric
Eric,
Thanks for the feedback - any bugs which you report which I can
reproduce - I will treat
as a very high priority and your testing is helpful.
> Trying to push Linux in corporate environments in such condition is very
> difficult because, due to those bugs, you cannot:
>
> 1) save a new openoffice document twice,
> 2) create mail folders from inside thunderbird (local mailbox
shared
> with windows),
You can avoid these by mounting with "nobrl" (no remote byte range lock)
mount option
(smbfs does not send byte range locks so would not run into this
problem, but would run
into others). These appear to be byte range locking problems. The
problem is that cifs has
to map advisory to mandatory locks which only works if the application
is reasonably well
behaved (not even Samba has support for advisory locks although
they will come with the new Unix extensions). It may be made worse by a
bug in openoffice
(some Linux apps such as Evolution lock on the "wrong" file handle which
does not fail in posix,
although is sloppy coding) but I have not confirmed the byte range lock
sequence which
openoffice is trying as we did with Evolution - I did confirm that nobrl
(disabling the
byte range locks on the client) works. Note that this mount option,
although not listed
as a bug fix in git per-se - was added to address the evolution etc.
locking bugs. There
are quite a few of the cifs changes that fall into that category.
> 3) avoid to do FSCK after each reboot,
Not sure that cifs would cause this unless you mean that cifs was hung
and shutdown hung. To
avoid cases where cifs requests could stay blocked forever (especially
locking requests),
I added a umount_begin routine a few weeks ago to try to free threads
blocked in cifs -
but what I need from users/tests if they see a cifs umount fail is to
know where the requests
are hung so I can add wakeup calls for that condition in
cifs's umount_begin (you can do "echo t > /proc/sysrq-trigger" then
"dmesg > debugdata" to get
the debugdata which has the callstacks of processes blocked in kernel).
> I've seen many changes going in CIFS git tree during this period but
> only few bugs got really hunted and fixed
Scanning the bugzilla list I don't see many which are still believed to
be valid, but
the bugzilla list for cifs on bugzilla.samba.org needs to be cleaned up.
>SMBfs do not exibit some of the bugs CIFS has but has other limitations
SMBfs runs far fewer posix applications. The main advantage smbfs
has is in its kerberos support (which is being worked with the new cifs
upcall) and in that it cheats and opens multiply open files only once and
with the wrong flags (which can help performance in some cases
but the lack of safe caching can lead to data corruption).
>Could other on the LKML list try to reproduce/confirm the following bugs
>with the latest snapshot:
That would be very helpful.
> NB : the second bug appeared with CIFS 1.39 and is not present in
2.6.14.2
>
The smb length checking code was fixed in cifs 1.38 or cifs 1.39 (it was
missing some
illegal cases where tcp length of the smb did not match the calculated
smb length of
the three parts of the smb). It of course could be a security exposure to
overly relax the length checking code on incoming
network buffers. Unfortunately Windows server has at least one bug in which
its server miscalculates the size of an smb with no data area but an
illegal pad but the empty bcc (byte data) area of an SMB - this can
occur on
byte range locks but we may be seeing a second case in your example.
> BUGS :
> <https://bugzilla.samba.org/show_bug.cgi?id=2673>
I suspect that this is a difference in default ACLs or share permissions
on the windows server side, but
as I have mentioned additinal data would be helpful as no one else so
far has been able to reproduce it
as far as I know. If that is not the cause it may be a problem with
the emulation of Linux mode
bits - and of course some three or four of the most recent cifs changes
have been working case by
case through improving this to Windows servers. It is not easy code to
discover and write.
> <https://bugzilla.samba.org/show_bug.cgi?id=3237>
I would like to see the debug data ("cat /proc/fs/cifs/DebugData") so I
can see if there any
pending network requests when your shutdown occurs - and I want to see
an ethereal trace
(or tcpdump or equivalent binary trace file) of this so I can see what
is going on with this
malformed response from the server.
> May I suggest to fix bugs as a priority before adding new features for a
If there is a known bug, reported and which I can recreate - it is of
course my highest priority
and I would also evaluate patches to fix such as my highest priority -
but if they are hard
or impossible for me to recreate - getting the very, very, very hot
issue of Kerberos security
enablement finished is the priority now.
> Or at least make sure enough testing is done to avoid regressions?
There is a large test suite of the typical Linux fs tests (connectathon
posix file api,
fsx, fsstress, dbench, etc.) which is run against Samba and Windows on
every
update of cifs (by me and Shaggy and others who can help from time to time).
I would love additional testing in the user community especially on a
broader set of servers
than I can test - one person can't possibly have enough servers to test
every one of the
variations of Windows servers or even Samba/unix platform variants -
and there
are dozens of other nas appliances and cifs servers.
Although I would like to find a workaround so it does not hang the
umount or fail umount
I am not convinced that this is a typical regression - if a server sends
an illegal response which
we were not catching before ... it would be dangerous to call preventing
that potential
security problem a regression.
Steve French wrote:
> Eric,
> Thanks for the feedback - any bugs which you report which I can
> reproduce - I will treat
> as a very high priority and your testing is helpful.
I know you have tried to reproduce them and failed. The question was how
to go further?
>> Trying to push Linux in corporate environments in such condition is
>> very difficult because, due to those bugs, you cannot:
>>
>> 1) save a new openoffice document twice, 2) create mail folders
>> from inside thunderbird (local mailbox
> shared
>> with windows),
>
> You can avoid these by mounting with "nobrl" (no remote byte range
> lock) mount option (smbfs does not send byte range locks so would not
> run into this problem, but would run into others). These appear to be
> byte range locking problems. The problem is that cifs has to map
> advisory to mandatory locks which only works if the application is
> reasonably well behaved (not even Samba has support for advisory
> locks although they will come with the new Unix extensions). It may
> be made worse by a bug in openoffice (some Linux apps such as
> Evolution lock on the "wrong" file handle which does not fail in
> posix, although is sloppy coding) but I have not confirmed the byte
> range lock sequence which openoffice is trying as we did with
> Evolution - I did confirm that nobrl (disabling the byte range locks
> on the client) works. Note that this mount option, although not
> listed as a bug fix in git per-se - was added to address the
> evolution etc. locking bugs. There are quite a few of the cifs
> changes that fall into that category.
Well I would be surprised the "cat >> titi" command does any of this
byte range lock. If the "create and later rewrite the same file"
sequence fails, with a simple cat command (cat > titi ... ^D; cat >>
titi), how can it works with complicated applications?
>
>> 3) avoid to do FSCK after each reboot,
> Not sure that cifs would cause this unless you mean that cifs was
> hung and shutdown hung.
Yes : the system hangs when shutting down as the result of the "umount
-a" with the last message being as described in bug N? 3237. I have to
press power button for 5 seconds.
NB : manually doing the umount does exactly the same things.
> To avoid cases where cifs requests could stay
> blocked forever (especially locking requests), I added a umount_begin
> routine a few weeks ago to try to free threads blocked in cifs - but
> what I need from users/tests if they see a cifs umount fail is to
> know where the requests are hung so I can add wakeup calls for that
> condition in cifs's umount_begin (you can do "echo t >
> /proc/sysrq-trigger" then "dmesg > debugdata" to get the debugdata
> which has the callstacks of processes blocked in kernel).
Will do that in the bug data.
>> <https://bugzilla.samba.org/show_bug.cgi?id=3237>
> Although I would like to find a workaround so it does not hang the
> umount or fail umount I am not convinced that this is a typical
> regression - if a server sends an illegal response which we were not
> catching before ... it would be dangerous to call preventing that
> potential security problem a regression.
Hanging a system systematically leading to FSCK on each reboot is not
particularly helpfull given the fact that it happens whebn you are doing
a shutdown in most cases.
-- eric
VALETTE Eric RD-MAPS-REN wrote:
>Steve French wrote:
>
>
>>Eric,
>>
>>
>Well I would be surprised the "cat >> titi" command does any of this
>byte range lock. If the "create and later rewrite the same file"
>sequence fails, with a simple cat command (cat > titi ... ^D; cat >>
>titi), how can it works with complicated applications?
>
>
>
Make sure that you let me know if your cat example works when mounted
with the relatively new "noperm" mount option on the client. At least
then we will know whether we are looking at a problem with access
control on the server (ntfs acls) or client (unix mode bits and the
.permission entry point)
VALETTE Eric RD-MAPS-REN wrote:
>>>1) save a new openoffice document twice, 2) create mail folders
>>>from inside thunderbird (local mailbox
>>>
>>>
>>shared
>>
>>
>>>with windows),
>>>
>>>
>>You can avoid these by mounting with "nobrl" (no remote byte range
>>lock) mount option (smbfs does not send byte range locks so would not
>>run into this problem, but would run into others). These appear to be
>>byte range locking problems. The problem is that cifs has to map
>>advisory to mandatory locks which only works if the application is
>>reasonably well behaved (not even Samba has support for advisory
>>locks although they will come with the new Unix extensions). It may
>>be made worse by a bug in openoffice (some Linux apps such as
>>Evolution lock on the "wrong" file handle which does not fail in
>>posix, although is sloppy coding) but I have not confirmed the byte
>>range lock sequence which openoffice is trying as we did with
>>Evolution - I did confirm that nobrl (disabling the byte range locks
>>on the client) works. Note that this mount option, although not
>>listed as a bug fix in git per-se - was added to address the
>>evolution etc. locking bugs. There are quite a few of the cifs
>>changes that fall into that category.
>>
>>
>
>Well I would be surprised the "cat >> titi" command does any of this
>byte range lock. If the "create and later rewrite the same file"
>sequence fails, with a simple cat command (cat > titi ... ^D; cat >>
>titi), how can it works with complicated applications?
>
>
>
The "cat >> titi" failure has nothing to do with the Evolution and
OpenOffice issues. We have had multiple people reproduce the strange
Evolution behavior that was causing problems (months ago) and those can
be handled now. Those applications do byte range locking in
counter-intuitive ways that are hard to map onto the network (and also
Evolution IIRC also uses "illegal" (to CIFS, but legal to POSIX)
characters in file names - which we also had to add a mount option for -
in order to allow remapping of those characters). The cat failure that
you describe is likely due to 1) either the need for a full emulation of
Unix mode bits to Windows ACLs when umask is set to certain values or 2)
a strange combination of share permissions and ntfs acls on the server
side which allow create in the directory but not append on new file objects.
>Yes : the system hangs when shutting down as the result of the "umount
>-a" with the last message being as described in bug N? 3237. I have to
>press power button for 5 seconds.
>
>NB : manually doing the umount does exactly the same things.
>
>
>
This looks like a corrupt server frame - I will try to get change samba
to force such an illegal frame to test the changes, but it looks like
something we can work around with defensive code in the cifs client:
1) by allowing a minimum sized response to have an illegal bcc (byte
area count) under this circumstance
2) by making sure SMBLogoffX times out faster (since it is harmless
to do that in most cases - it is often followed by a tcp session close
which will implicitly do what SMBLogoffX does anyway)
Steve French wrote:
> VALETTE Eric RD-MAPS-REN wrote:
>
>>>> 1) save a new openoffice document twice, 2) create mail folders
>>>> from inside thunderbird (local mailbox
>>>>
>>>
>>> shared
>>>
>>>
>>>> with windows),
>>>>
>>>
>>> You can avoid these by mounting with "nobrl" (no remote byte range
>>> lock) mount option (smbfs does not send byte range locks so would not
>>> run into this problem, but would run into others). These appear to be
>>> byte range locking problems. The problem is that cifs has to map
>>> advisory to mandatory locks which only works if the application is
>>> reasonably well behaved (not even Samba has support for advisory
>>> locks although they will come with the new Unix extensions). It may
>>> be made worse by a bug in openoffice (some Linux apps such as
>>> Evolution lock on the "wrong" file handle which does not fail in
>>> posix, although is sloppy coding) but I have not confirmed the byte
>>> range lock sequence which openoffice is trying as we did with
>>> Evolution - I did confirm that nobrl (disabling the byte range locks
>>> on the client) works. Note that this mount option, although not
>>> listed as a bug fix in git per-se - was added to address the
>>> evolution etc. locking bugs. There are quite a few of the cifs
>>> changes that fall into that category.
>>>
>>
>>
>> Well I would be surprised the "cat >> titi" command does any of this
>> byte range lock. If the "create and later rewrite the same file"
>> sequence fails, with a simple cat command (cat > titi ... ^D; cat >>
>> titi), how can it works with complicated applications?
>>
>>
>>
> The "cat >> titi" failure has nothing to do with the Evolution and
> OpenOffice issues. We have had multiple people reproduce the strange
> Evolution behavior that was causing problems (months ago) and those can
> be handled now. Those applications do byte range locking in
> counter-intuitive ways that are hard to map onto the network (and also
> Evolution IIRC also uses "illegal" (to CIFS, but legal to POSIX)
> characters in file names - which we also had to add a mount option for -
> in order to allow remapping of those characters). The cat failure that
> you describe is likely due to 1) either the need for a full emulation of
> Unix mode bits to Windows ACLs when umask is set to certain values or 2)
> a strange combination of share permissions and ntfs acls on the server
> side which allow create in the directory but not append on new file
> objects.
I'm affraid the OpenOffice issue is indeed caused by the same EACESS
unless you prove me I'm wrong. Usually to create a presentation, I open
an existing one (via CIFS), save it to a new name (on the server via
CIFS) to avoid corrupting the old one (create a file), then modyfy it,
then try to write it (do not manage to modify it). I made the "cat bug"
just to strip the problem to the bare minimum.
>
>> Yes : the system hangs when shutting down as the result of the "umount
>> -a" with the last message being as described in bug N? 3237. I have to
>> press power button for 5 seconds.
>>
>> NB : manually doing the umount does exactly the same things.
>>
>>
>>
> This looks like a corrupt server frame - I will try to get change samba
> to force such an illegal frame to test the changes, but it looks like
> something we can work around with defensive code in the cifs client:
> 1) by allowing a minimum sized response to have an illegal bcc (byte
> area count) under this circumstance
> 2) by making sure SMBLogoffX times out faster (since it is harmless
> to do that in most cases - it is often followed by a tcp session close
> which will implicitly do what SMBLogoffX does anyway)
This makes me *really* wonder how you test your CIFS implementation. I
would bet you use a Linux server with samba and not real Windows servers
like Windows 2000 server or Windows 2003 server. I can perfectly
understand that for development purpose because you can tarce the both
side, then for validation I think using WindoWS NT (Ok Obsolete but
still), Windows 2000 server or Windows 2003 server is mandatory.
-- eric
Steve French wrote:
> VALETTE Eric RD-MAPS-REN wrote:
>
>> Steve French wrote:
>>
>>
>>> Eric,
>>>
>>
>> Well I would be surprised the "cat >> titi" command does any of this
>> byte range lock. If the "create and later rewrite the same file"
>> sequence fails, with a simple cat command (cat > titi ... ^D; cat >>
>> titi), how can it works with complicated applications?
>>
>>
>>
> Make sure that you let me know if your cat example works when mounted
> with the relatively new "noperm" mount option on the client. At least
> then we will know whether we are looking at a problem with access
> control on the server (ntfs acls) or client (unix mode bits and the
> .permission entry point)
The simple "cat > titi ..^D ; cat >> titi" case works when mounted with
the noperm option.
BTW : the fstab content is now :
\\r-canaris\ceva6380 /network/home cifs
domain=FTRD,noperm,credentials=/home/ceva6380/.s
ambaShareId 0 0
and the .sambaShareId contains my windows domain (FTRD) login id (same
as $USER value BTW) and the associated password and "umask" at shell
prompts return 0022.
Hope this helps.
--eric
Steve French wrote:
> VALETTE Eric RD-MAPS-REN wrote:
>
>> Steve French wrote:
>>
>>
>>> Eric,
>>>
>>
>> Well I would be surprised the "cat >> titi" command does any of this
>> byte range lock. If the "create and later rewrite the same file"
>> sequence fails, with a simple cat command (cat > titi ... ^D; cat >>
>> titi), how can it works with complicated applications?
>>
>>
>>
> Make sure that you let me know if your cat example works when mounted
> with the relatively new "noperm" mount option on the client. At least
> then we will know whether we are looking at a problem with access
> control on the server (ntfs acls) or client (unix mode bits and the
> .permission entry point)
Works with the "noperm" mount option.
--eric
VALETTE Eric RD-MAPS-REN wrote:
>Steve French wrote:
>
>
>>VALETTE Eric RD-MAPS-REN wrote:
>>
>>
>>
>>>Steve French wrote:
>>>
>>>
>>let me know if your cat example works when mounted
>>with the relatively new "noperm" mount option on the client. At least
>>then we will know whether we are looking at a problem with access
>>control on the server (ntfs acls) or client (unix mode bits and the
>>.permission entry point)
>>
>>
>
>Works with the "noperm" mount option.
>
>--eric
>
>
>
OK - That is good, should be relatively easy to debug from here.
To explain what is going on, here is some obvious background. Windows
uses a rich ACL model locally and over the network via CIFS (other
protocols such as NFSv4 now do something similar) and Windows of course
does not have really have or need Unix mode bits ... and the server
(unlike Samba and those that implement the standard SNIA CIFS Unix
extensions) does not return emulated mode bits (although it does locally
in Windows "services for Unix" and of course also cygwin does something
similar) ... so the cifs client has to approximate mode bits. If the
client makes an incorrect approximation you can get access denied on a
client side permission check. Of course some would argue that for
clients that are running as single user desktop clients the client does
not need to do perm checks (the server does ACL checks) so just turn off
the client permission checks - that is why the "noperm" option is
available on the cifs client.
So the choices today are:
1) Turn off mode bit checking (on the client) on a particular cifs mount
(noperm mount option)
or
2) pass in a default mode and uid or gid on the cifs mount that matches
what you want (otherwise cifs will use the uid of the mounter, and a
default mode). Although cifs caches the mode bits in the inode if they
are modified by an app on the client e.g. via chmod (while the inode
stays in memory on the client) - for querying (lookups/stat) on existing
files cifs can only use the +R dos attribute to distinguish when to
return something other than 0777 (or the default).
or
3) turn on the "sfu" mount option on the client and let cifs make the
(more expensive) queries to the server for mode information the same way
that "services for unix" would. This does not work for all mode bits
yet, as it requires additional CIFS ACL support to be coded, but it does
now work for the 3 bits above 0777 (as of just after 2.6.15-rc2).
Following the suggestions of Martin Koeppe and others there may be a
need to allow a "cygwin" mount option as well.
VALETTE Eric RD-MAPS-REN wrote:
>Steve French wrote:
>
>
>>VALETTE Eric RD-MAPS-REN wrote:
>>
>>
>>
>>>Steve French wrote:
>>>
>>>
>>>
>>>
>>>>Eric,
>>>>
>>>>
>>>>
>>>Well I would be surprised the "cat >> titi" command does any of this
>>>byte range lock. If the "create and later rewrite the same file"
>>>sequence fails, with a simple cat command (cat > titi ... ^D; cat >>
>>>titi), how can it works with complicated applications?
>>>
>>>
>>>
>>>
>>>
>>Make sure that you let me know if your cat example works when mounted
>>with the relatively new "noperm" mount option on the client. At least
>>then we will know whether we are looking at a problem with access
>>control on the server (ntfs acls) or client (unix mode bits and the
>>.permission entry point)
>>
>>
>
>Works with the "noperm" mount option.
>
>--eric
>
>
>
Could you run "stat titi" and/or "ls -l titi" between the
"cat > titi"
and the
"cat >> titi"
so I can see what cifs thinks the owner of the file is and the mode. I
also need to know the current user so I can see whether it matches what
cifs has as the owner of the file. Note that readdir (ls of a
directory or ls with a wildcard) and lookup (ls of a specific file, or
stat) hit different code paths in the cifs vfs but both cause default
mode bits to be put in the inode metadata.
If this does not point out the problem, then I will give you a modified
version of cifs_permission to trace what is happening.
Steve French wrote:
>>This makes me *really* wonder how you test your CIFS implementation. I
>>would bet you use a Linux server with samba and not real Windows servers
>>like Windows 2000 server or Windows 2003 server. I can perfectly
>>understand that for development purpose because you can tarce the both
>>side, then for validation I think using WindoWS NT (Ok Obsolete but
>>still), Windows 2000 server or Windows 2003 server is mandatory.
> There are two big test events for CIFS each year (Connectathon and the
> SNIA CIFS conference) in which all of the major CIFS vendors servers and
> clients (including the Linux cifs client) are tested together. These
> two events has been the most helpful for me every year as they are for
> many others on the Samba team (lots of Samba server progress also
> happens in these two weeks). That is the best opportunity (almost the
> only good opportunity) for testing against EMC, NetApp, Adaptec/SNAP,
> AIX FastConnect, and the other NAS vendors - and at each event a few
> client bugs have been fixed or client workarounds for server bugs have
> been added as a result of this testing. For weekly testing there are
> of course more test environments than mine, and I get feedback from
> those testing against other server versions, but I have a small test
> environment at home and also one at work (there are other unrelated test
> groups that test the version of cifs and Samba before distro releases)
> that I regularly test against. It would be impossible for one person to
> test against the breadth of servers out there so community testing,
> especially against the less well known servers, is encouraged.
That is great that such "plug fest" exists and I agree with you that
this is the only way to test compatibility to such scale.
> In my test environment these are tested almost daily as target servers:
>
> 1) Samba version 3 (current)
> 2) Windows XP service pack 2
Do you have collected any statistics on Windows server market share per
windows version? I would bet 2000 Server is still mainstream with 2003
slowly replacing NT4 in term of percentage now that support is stopped.
Idealy, may I suggest that dayly testing platforms, should match this
real life Winddows server platform distribution.
-- eric
Steve French wrote:
> To explain what is going on, here is some obvious background. Windows
> uses a rich ACL model locally and over the network via CIFS (other
> protocols such as NFSv4 now do something similar) and Windows of course
> does not have really have or need Unix mode bits ... and the server
> (unlike Samba and those that implement the standard SNIA CIFS Unix
> extensions) does not return emulated mode bits (although it does locally
> in Windows "services for Unix" and of course also cygwin does something
> similar) ... so the cifs client has to approximate mode bits. If the
> client makes an incorrect approximation you can get access denied on a
> client side permission check. Of course some would argue that for
> clients that are running as single user desktop clients the client does
> not need to do perm checks (the server does ACL checks) so just turn off
> the client permission checks - that is why the "noperm" option is
> available on the cifs client.
>
> So the choices today are:
>
> 1) Turn off mode bit checking (on the client) on a particular cifs mount
> (noperm mount option)
I could live with that altthough there is something I would like to
clarify (see below).
> or
> 2) pass in a default mode and uid or gid on the cifs mount that matches
> what you want (otherwise cifs will use the uid of the mounter, and a
> default mode). Although cifs caches the mode bits in the inode if they
> are modified by an app on the client e.g. via chmod (while the inode
> stays in memory on the client) - for querying (lookups/stat) on existing
> files cifs can only use the +R dos attribute to distinguish when to
> return something other than 0777 (or the default).
If you put something is a /etc/fstab, that will be mounted by init
scripts, the uid/gid credentials attached with the mount request is of
course root.root (which is wht is see with "ls file" BTW). 'I'm just
surprised that with the perm option, my identity seems to change, on the
client side, between the two commands : if the file is marked locally as
created by root.root, I should still be root.root for the next command!
Side question for my understanding : when I specify the credentials
(like I did) (credentials=/home/ceva6380/.sambaShareId) and that the
user name exist in the local /etc/passwd, I'm surprised to have to add
the uid=getuidfrom(name) again. I admit, user name on the windows server
may be different than on the client, but to put a valid uid/gid it must
exist on the client system anyway and be consistent with the current
user identity no?
-- eric
Steve French wrote:
> VALETTE Eric RD-MAPS-REN wrote:
>
>>Steve French wrote:
>>
>>
>>>VALETTE Eric RD-MAPS-REN wrote:
>>>
>>>
>>>
>>>>Steve French wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Eric,
>>>>>
>>>>>
>>>>>
>>>>Well I would be surprised the "cat >> titi" command does any of this
>>>>byte range lock. If the "create and later rewrite the same file"
>>>>sequence fails, with a simple cat command (cat > titi ... ^D; cat >>
>>>>titi), how can it works with complicated applications?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>Make sure that you let me know if your cat example works when mounted
>>>with the relatively new "noperm" mount option on the client. At least
>>>then we will know whether we are looking at a problem with access
>>>control on the server (ntfs acls) or client (unix mode bits and the
>>>.permission entry point)
>>>
>>>
>>
>>Works with the "noperm" mount option.
>>
>>--eric
>>
>>
>>
> Could you run "stat titi" and/or "ls -l titi" between the
> "cat > titi"
> and the
> "cat >> titi"
cat > toto
toto
8 r-ptxp-ceva6380:/network/home/test3->ls -l toto
-rw-r--r-- 1 root root 5 2005-11-22 17:50 toto
9 r-ptxp-ceva6380:/network/home/test3->cat >>titi
tata
10 r-ptxp-ceva6380:/network/home/test3->ls -l toto
-rw-r--r-- 1 root root 5 2005-11-22 17:50 toto
OK, I'm not root.root but why does my identity seem to change between
the file creation and the file rewrite?
-- eric