[linux-cifs-client] interoperability between samba, linux-cifs,
cywgin and sfu
Martin Koeppe
mkoeppe at gmx.de
Thu Dec 1 13:18:10 GMT 2005
Hello,
[please cc me on replies]
while playing around with a Windows server (2003), a Linux server
(2.6.11) with Samba (3.0.14a) and a Windows client (2000) with both
Interix Services for Unix (SFU) (3.5) and Cygwin (1.5.19pre20051130)
installed, I encountered the following problems or inconsistencies
when using on the one hand SFU and Cygwin on Windows and Samba network
shares, and on the other hand when using linux-cifs on Windows shares,
where locally Cygwin or SFU are used.
Most of these problems have been already discussed, and some of them
have been solved in between, but I'm cross-posting this summary now to
all lists involved on that, I hope at least.
Here interoperability is meant as storing special unix file attributes
(special files, mode bits and user/group ids) in such a way, that they
ideally are interpreted in the same way by all Windows<->Unix
connecting software.
(I have marked in [], which of the software mentioned in this mail's
subject I think should be changed for better interoperability.)
1. storage of special files such as symlinks, fifos, devs [all]
================================================================
The way that SFU stores these special files, I tried to explore at:
http://lists.samba.org/archive/linux-cifs-client/2005-May/000856.html
Cygwin has its own way which I observed by a quick look (so may not
be completely correct):
http://lists.samba.org/archive/linux-cifs-client/2005-November/001080.html
A concrete problem on cygwin is that you can create device files, but
these device files are shown as symlinks instead of as device files
(even on C:), i.e.
cygwin$ mknod myblock b 0 0
cygwin$ ls -l
lrwxrwxrwx 1 martin mkpasswd 10 Nov 30 23:10 myblock -> :\0:0:61b6
cygwin$ test -b myblock && echo "block"
[ does not echo "block", so is not seen as a block device file ]
cygwin$ test -l myblock && echo "link"
bash: test: -l: unary operator expected
cygwin$ perl -e '-l "myblock" && print "link"'
link
So "test" dies unexpectedly, but perl doesn't. Another problem.
cygwin$ mkfifo myfifo && ls -l myfifo
prw-rw-rw- 1 martin mkpasswd 102 Nov 30 23:09 myfifo
The fifo is made correctly and shown as such, but has a file size of
102 which is <>0, so not, what I would have expected.
It would be nice if Cygwin could store these files in the same way as
SFU. And Samba could then convert the SFU method to real device and
fifo files on the disk. For the cifs client, work has begun to include
the SFU way:
http://lists.samba.org/archive/linux-cifs-client/2005-November/001073.html
The only thing one could discuss is how to store symlinks. Cygwin's
symlinks can be followed in Windows Explorer, whereas SFU symlinks are
more consistent, as they are named exactly the same on the
underlying disk, no .lnk appended.
2. test -l does not work [cygwin]
=================================
I repeat this here from above for clarity:
cygwin$ test -l a_link && echo "link"
bash: test: -l: unary operator expected
cygwin$ perl -e '-l "a_link" && print "link"'
link
So "test" dies unexpectedly, but perl doesn't.
3. set file bits [all]
=======================
SFU stores the set file bits in an extended attribute called
SETFILEBITS, for details see:
http://lists.samba.org/archive/linux-cifs-client/2005-June/000865.html
Cygwin seems to store the set bits with the help of a special acl
entry for the "NULL SID". At least chmod 07777 creates such an acl
entry, and after manually deleting it, the file has no longer set bits
set in cygwin's opinion.
While both of these methods can be used to store these infos on a
windows server share, it would be nice, if it could be stored by a
samba server as well, ideally in such a way, that locally on the samba
server the file mode is the same as within SFU and/or Cygwin.
The cifs client ideally should show and set these mode bits as well
from within linux, when one runs Cygwin and/or SFU on a Windows
server. Work is in progress on that, see:
http://lists.samba.org/archive/linux-cifs-client/2005-November/001073.html
4. file and directory lower 9 mode bits [all]
==============================================
While Corinna has written a good howto on mapping the mode bits on
Windows ACL entries:
http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping
I found one issue not documented there though:
Suppose you have on Windows the following directories:
C:\temp\t1\t2
Now you change the permissions with explorer in the following way:
t2: has access allowed for the current user (non-inherited)
t1: all ACL entries are removed
You can now do the following on a CMD.EXE:
C:\temp> cd t1
Permission denied!
C:\temp> cd t1\t2
C:\temp\t1\t2>
So chdir into t2 is possible.
On Cygwin t1 is shown by ls as d---------, but "cd t1/t2" nevertheless
works.
On interix sfu, t1 is also shown as d---------, but "cd t1/t2" doesn't
work. Even though it works via Windows Explorer or CMD.EXE.
I don't know which behaviour should be implemented here, I just
wanted to document the differences.
Maybe the following on FILE_TRAVERSE and BYPASS_TRAVERSE_CHECKING is
helpful:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/file_security_and_access_rights.asp
5. normal files [samba]
=======================
Within the SFU environment, normal files from a samba server are
incorrectly shown as directories, see:
https://bugzilla.samba.org/show_bug.cgi?id=3295
6. uid/gid [samba]
==================
On a samba (3.0.14a and 3.0.21rc1) mounted drive G: sfu's ls shows
different uids when called with or without -n:
C:\SFU\common>ls.exe -l G:\file.txt
-rwxr--r-- 1 3001 3001 6 Dec 1 11:37 /dev/fs/G/file.txt
C:\SFU\common>ls.exe -ln G:\file.txt
-rwxr--r-- 1 3000 3001 6 Dec 1 11:37 /dev/fs/G/file.txt
This is only on samba drives, on Windows drives, for the non -n call,
Windows user names are shown:
C:\SFU\common>ls.exe -l C:\config.sys
-rwxrwxrwx 1 +Administratoren +SYSTEM 0 May 11 2003 /dev/fs/C/CONFIG.SYS
C:\SFU\common>ls.exe -ln C:\config.sys
-rwxrwxrwx 1 131616 66834 0 May 11 2003 /dev/fs/C/CONFIG.SYS
7. hard links and inode numbers [cygwin]
========================================
While Cygwin now reports link count and inode numbers on network
drives correctly, SFU reports the inode numbers correctly (modulo an
issue with samba), but the link count on network drives is always
reported as "1". Maybe that's intentional. See:
http://cygwin.com/ml/cygwin/2005-11/msg00854.html
https://bugzilla.samba.org/show_bug.cgi?id=3287
8. CreateHardLink() Windows API [cygwin] [ActivePerl]
======================================================
The CreateHardLink() Windows API function isn't apparently able to
create hardlinks on network drives, whereas with the sfu ln utility,
you can. Both C:\sfu\common\ln.exe and C:\sfu\bin\ln work, where the
former seems to call the latter internally. As CreateHardLink() is
used by cygwin (and ActivePerl, too), you cannot with these.
Unfortunately, the error returned by CreateHardLink() doesn't say
"hardlinks not supported", but it says "file not found":
cygwin$ ln file file2
ln: creating hard link `file2' to `file': No such file or directory
See for a possible solution:
http://cygwin.com/ml/cygwin-patches/2005-q2/msg00091.html
http://cygwin.com/ml/cygwin-patches/2005-q2/msg00093.html
http://bugs.activestate.com/show_bug.cgi?id=39027
Martin
More information about the linux-cifs-client
mailing list