RE: Kerberized SMB client? User level SMB client?
On Mon, 16 Dec 2002, Naomaru Itoi wrote: Thanks, Steve, I was actually asking about SMB/CIFS client *filesystem*. Excuse me for being unclear ... smbfs (not userspace) works just fine (*) with kerberos. All kerberos work is done by smbmount (userspace) and that code is the same as the one used by smbclient. The filesystem parts doesn't care about kerberos when it is only used for authentication. smbfs signals back to smbmount if it wants it to reconnect. But perhaps you wanted more than authentication. /Urban * - Well, it needs some changes to use ntstatus error codes, but that has nothing to do with kerberos.
Re: Smbmount password interfaces
On Mon, 11 Nov 2002, W. Michael Petullo wrote: Could you implement a similar option in smbmount? When the current version of smbmount prompts for a password, it tries to read it from /dev/tty. Allowing a user to tell smbmount to read its password from stdin would make smbmount more flexible in pipelines. You should be able to set PASSWD_FD to a file descriptor to read the password from. (see source/client/smbmount.c:get_password_file) Not that I have a problem with adding 'passwordfd=0' if that makes it any easier for you. /Urban
Re: Planning 3.0alpha21 for Friday (10/25)
On Wed, 23 Oct 2002, Gerald (Jerry) Carter wrote: Any chance of someone reviewing and possibly adding these changes before then? I first posted this on the 19th. I'll grab them. Did you do anything with it beyond grabbing ... :) As far as my cvs client can tell this had not made it in yet. Here it is again, minus the part that wouldn't work for all multibyte charsets. For 3_0 and HEAD. /Urban diff -urN -X exclude samba-3_0.old/source/libsmb/cliconnect.c samba-3_0/source/libsmb/cliconnect.c --- samba-3_0.old/source/libsmb/cliconnect.cThu Oct 17 19:10:24 2002 +++ samba-3_0/source/libsmb/cliconnect.cSat Oct 19 12:13:30 2002 -124,6 +124,9 if (cli-capabilities CAP_UNICODE) capabilities |= CAP_UNICODE; + if (cli-capabilities CAP_LARGE_FILES) + capabilities |= CAP_LARGE_FILES; + return capabilities; } diff -urN -X exclude samba-3_0.old/source/lib/util_unistr.c samba-3_0/source/lib/util_unistr.c --- samba-3_0.old/source/lib/util_unistr.c Wed Sep 25 17:18:52 2002 +++ samba-3_0/source/lib/util_unistr.c Sat Oct 19 20:45:34 2002 -335,6 +335,7 if (c == *s) return (smb_ucs2_t *)s; s++; } + if (c == *s) return (smb_ucs2_t *)s; return NULL; }
Re: smbfs missing files
On Tue, 5 Nov 2002, Jeff Ames wrote: This sounds like the same problem as the bug reports 21471, 21407, 21561, and 21694 discuss, but I couldn't find a solution anywhere. I'm just I guess I should update those... writing to add a data point, and also to ask whether there is any known fix or workaround for this at the time. If this would be better submitted as a bug report instead of this list, please let me know. There is a known problem with win2k listings. It doesn't like us using the continue bit at all. You should be able to trigger this with smbclient too. Try this patch for 2.4.19 http://www.hojdpunkten.ac.se/054/samba/smbfs-2.4.19-rc1-ALL.patch.gz It changes smbfs to use the same method as win2k does when listing files on another win2k machine (there is a lot of other stuff in there too, including 2G files and unicode). Note that there is a known report of this breaking listings vs NT4, which is why the change hasn't been made in the official kernel yet. I have been meaning to compare what win2k sends to and NT4 when listing and see if it does anything differently from win2k-win2k. I guess it could be a NT4/non-unicode-client issue. /Urban
Re: CIFS woes (fwd)
On Wed, 30 Oct 2002, Paul D. Robertson wrote: the local machine as a CIFS filesystem. Here's my issue- I can't execute a binary file if it's on the share. Doesn't mater if it's ELF or a.out format, or if it's static or dynamic. Scripts run just fine, but binaries give me: -bash: ./command: cannot execute binary file along with modprobe: modprobe: Can't locate module binfmt-464c in syslog (which means the binformat isn't recognized AFAICT- noramlly an architecture or endian mismatch?) binfmt-464c is ELF -- it means your kernel came across an ELF executable and was unable to execute it so it tried to load the ELF binary format module. Since you have ELF compiled into your kernel already, this didn't work. http://www.uwsg.iu.edu/hypermail/linux/kernel/0102.3/0006.html I've tried compiling an executable on the CIFS filesystem, same results, moving the binary to a local filesystem works just fine, but once it's copied back, it won't execute, so it's not the contents of the file. AFAIK, ELF requires that the filesystem implements mmap in some form so you are probably using a version that doesn't. For a.out, I think it depends on the a.out type. Some are demand pageable, others are not. Any ideas/pointers/clues would be most helpful at this point. You could try: http://uranus.it.swin.edu.au/~jn/linux/smbfs/ /Urban
Re: Planning 3.0alpha21 for Friday (10/25)
On Wed, 23 Oct 2002, Gerald (Jerry) Carter wrote:
Just giving everyone a heads up. I will also roll RPMS
for the various RedHat versions on this release.
Any chance of someone reviewing and possibly adding these changes before
then? I first posted this on the 19th.
3 changes smbmount wants in samba:
1) Allow an application to control if CAP_LARGE_FILES is set in the
client capabilities.
2) Make strchr_m and strrchr_m efficient for the common case of searching for
an ascii character, using the same reasoning as in strlower_m.
The conversions done in strchr_m are kind of expensive ...
3) strchr_w(ws, UCS2_CHAR('\0')) doesn't find the end of the string,
and that makes strchr_m(string, '\0') fail. (2) fixes that, but I'm
guessing strchar_w is also supposed to work like strchr does.
/Urban
diff -urN -X exclude samba-3_0.old/source/libsmb/cliconnect.c
samba-3_0/source/libsmb/cliconnect.c
--- samba-3_0.old/source/libsmb/cliconnect.cThu Oct 17 19:10:24 2002
+++ samba-3_0/source/libsmb/cliconnect.cSat Oct 19 12:13:30 2002
-124,6 +124,9
if (cli-capabilities CAP_UNICODE)
capabilities |= CAP_UNICODE;
+ if (cli-capabilities CAP_LARGE_FILES)
+ capabilities |= CAP_LARGE_FILES;
+
return capabilities;
}
diff -urN -X exclude samba-3_0.old/source/lib/util_str.c
samba-3_0/source/lib/util_str.c
--- samba-3_0.old/source/lib/util_str.c Wed Oct 2 21:12:14 2002
+++ samba-3_0/source/lib/util_str.c Sat Oct 19 16:46:34 2002
-990,6 +990,9
pstring s2;
smb_ucs2_t *p;
+ if (!(c 0x80))
+ return strchr(s, c);/* ascii */
+
push_ucs2(NULL, ws, s, sizeof(ws), STR_TERMINATE);
p = strchr_w(ws, UCS2_CHAR(c));
if (!p)
-1005,6 +1008,9
pstring s2;
smb_ucs2_t *p;
+ if (!(c 0x80))
+ return strchr(s, c);/* ascii */
+
push_ucs2(NULL, ws, s, sizeof(ws), STR_TERMINATE);
p = strrchr_w(ws, UCS2_CHAR(c));
if (!p)
diff -urN -X exclude samba-3_0.old/source/lib/util_unistr.c
samba-3_0/source/lib/util_unistr.c
--- samba-3_0.old/source/lib/util_unistr.c Wed Sep 25 17:18:52 2002
+++ samba-3_0/sourcelib/util_unistr.c/ Sat Oct 19 20:45:34 2002
-335,6 +335,7
if (c == *s) return (smb_ucs2_t *)s;
s++;
}
+ if (c == *s) return (smb_ucs2_t *)s;
return NULL;
}
[PATCH] minor fixes for 3.0
3 changes smbmount wants in samba:
1) Allow an application using libsmb to control if CAP_LARGE_FILES is set
in the client capabilities.
2) Make strchr_m and strrchr_m efficient for the common case of searching for
an ascii character, using the same reasoning as in strlower_m.
The conversions done in strchr_m are kind of expensive ...
3) strchr_w(ws, UCS2_CHAR('\0')) doesn't find the end of the string,
and that makes strchr_m(string, '\0') fail. (2) fixes that, but I'm
guessing strchr_w is also supposed to work like strchr does.
patch vs SAMBA-3_0, please apply (to all relevant branches?)
/Urban
diff -urN -X exclude samba-3_0.old/source/libsmb/cliconnect.c
samba-3_0/source/libsmb/cliconnect.c
--- samba-3_0.old/source/libsmb/cliconnect.cThu Oct 17 19:10:24 2002
+++ samba-3_0/source/libsmb/cliconnect.cSat Oct 19 12:13:30 2002
-124,6 +124,9
if (cli-capabilities CAP_UNICODE)
capabilities |= CAP_UNICODE;
+ if (cli-capabilities CAP_LARGE_FILES)
+ capabilities |= CAP_LARGE_FILES;
+
return capabilities;
}
diff -urN -X exclude samba-3_0.old/source/lib/util_str.c
samba-3_0/source/lib/util_str.c
--- samba-3_0.old/source/lib/util_str.c Wed Oct 2 21:12:14 2002
+++ samba-3_0/source/lib/util_str.c Sat Oct 19 16:46:34 2002
-990,6 +990,9
pstring s2;
smb_ucs2_t *p;
+ if (!(c 0x80))
+ return strchr(s, c);/* ascii */
+
push_ucs2(NULL, ws, s, sizeof(ws), STR_TERMINATE);
p = strchr_w(ws, UCS2_CHAR(c));
if (!p)
-1005,6 +1008,9
pstring s2;
smb_ucs2_t *p;
+ if (!(c 0x80))
+ return strchr(s, c);/* ascii */
+
push_ucs2(NULL, ws, s, sizeof(ws), STR_TERMINATE);
p = strrchr_w(ws, UCS2_CHAR(c));
if (!p)
diff -urN -X exclude samba-3_0.old/source/lib/util_unistr.c
samba-3_0/source/lib/util_unistr.c
--- samba-3_0.old/source/lib/util_unistr.c Wed Sep 25 17:18:52 2002
+++ samba-3_0/sourcelib/util_unistr.c/ Sat Oct 19 20:45:34 2002
-335,6 +335,7
if (c == *s) return (smb_ucs2_t *)s;
s++;
}
+ if (c == *s) return (smb_ucs2_t *)s;
return NULL;
}
Re: debian: smbfs: support for large files (2GB) in sid with 2.4.19
On Mon, 14 Oct 2002, Andrew Bartlett wrote: The 'Samba Team' doesn't maintain smbfs, and without those changes a patch to smbmount doesn't make to much sense. That said, I don't mind applying them - but it's not been a priority. I have a bunch of changes, mostly bugfixes, that I wanted in 2.2.6 but the patch got lost in samba-patches. That's fine, I didn't push it, but it has been there since July ... (don't bother with that version anymore, btw). I plan to split up what I have and send smaller pieces to samba-technical, or where ever patches should be sent to. The release are on a separate branch? I guess I don't have to wait until after 2.2.6 then. This patch contains most of the changes: http://www.hojdpunkten.ac.se/054/samba/smbmount-2.2.5-misc-2.patch.gz I don't think it applies to 3.0 (but someone said it did?) but something similar is needed there, plus adding kerberos and spnego (+8/-6 lines). /Urban
Re: [Samba-Technical] Wrtiing files from one linux to another linux
On Wed, 28 Aug 2002, Kevin Liao wrote: Thanks for your reply. How about to disable the local kernel cache if the local system is running in the RAM disk so that we may have more memory to use and no need to worry about all of this? The local system isn't running in any ram disk when using smbfs. Even if you connect to a localhost samba server, that is a remote system as far as smbfs is concerned. I'm not sure I understood you here. /Urban
Re: [Samba-Technical] Wrtiing files from one linux to another linux
On Thu, 29 Aug 2002, Kevin Liao wrote: So when fsync() returns, it just means: 1. The remote server has successfully received the SMBflush request but not proceeded it yet. or 2. The remote server has successfully received and done the SMBflush request. When fsync returns (2) has happened. The server has read and responded to the SMBflush. But we don't know if it actually wrote anything to disk. There is no way the smbfs client can know what the other end does. The protocol specification says that it should sync to disk. /Urban
Re: [Samba-Technical] Wrtiing files from one linux to another linux
On Fri, 30 Aug 2002, Kevin Liao wrote: called an embedded system. Anyway the local machine will try to smbmount to the remote machine which is just a normal PC with linux installed. After the connection has been established successfully, the local system begins writing files continuously to the remote end. Therefore, what we want to do is to detect whether the file had been really saved in the remote storage device and if something goes wrong we may smbmount to another remote machine then keep working. To be sure the data is actually on disk you will need to do fsync. That is true for nfs as well (and you should consider using that instead). There is really nothing the client can do beyond fsync to detect if the server has written it to disk. As Andrew Bartlett said, the default setting of 'strict sync' is that samba lies to the client and says yes, I've written it to disk when it in fact has not. Regarding memory use, smbfs does not cache anything itself. It lets the kernel MM system to that for it (using the pagecache). When using mmap you can give hints on how you are accessing a file using madvise. But I don't know how well that works. Also note that when the system is low on memory the cached pages will be reused for other things. I believe details on how to tune certain MM parameters can be found in the kernel documentation. /Urban
Re: Was there a conv buffer prob in 2.2.1a?
On Fri, 30 Aug 2002, Michael Cuff wrote: Ok, I see what's happening. I'm glad someone does :) Client - Linux 2.4.7 based, smbmount version 2.2.1a I didn't think 2.2.1 sent share names as unicode strings. Or is this with some modified samba? ISTR some japanese patches ... /Urban
Re: [Samba-Technical] Wrtiing files from one linux to another linux
On Wed, 28 Aug 2002, Kevin Liao wrote: Then, no matter which one of the above two situations happens, the data is not yet written to the physical storage at that time, right? Should I need to call fsync() each time after calling write()? Thanks a lot! Yes, at each point where you want to ensure the data is written (not necessarily after each write). fsync() (and also fdatasync()?) will cause the local kernel to write any modified pages, and for smbfs it also sends a SMBflush that tells the other end to sync it to disk. For mmap()'ed data you can use msync(). Haven't tested if open(..., O_SYNC) works. /Urban
Re: smb_retry always show on console
On Wed, 17 Jul 2002 [EMAIL PROTECTED] wrote: My Console always show the following message: smb_retry: signal failed, error=-3 Is the error is genrate by Samba or my Linux. It's generated by smbfs (linux) and means that smbmount has terminated unexpectedly. To find the reason of that try specifying a higher debug level when mounting (try: debug=4) and see if you get anything useful written to smbmount.log (where the rest of the samba logfiles are). /Urban
Re: Quick Capabilities field question.
On Fri, 12 Jul 2002, Christopher R. Hertel wrote: The server sends its Capabilities data in the NegProt respoinse, and then the client replies with its Capabilities in the SESSION_SETUP_ANDX. The two values are ANDed... and the result is the agreed upon behavior. Is that close? Yes, agreed upon behavior is perhaps too strong. I don't see anything that says that either party promises to only use CAP_X. I'm trying, in particular, to see how NT 32-bit Status codes are negotiated. If both say CAP_STATUS32 what I have seen is that then it will be used. But nothing forces the server to actually send such error codes, it can still legally return dos error codes if it wants to by not setting bit 14 in the flags2 field of each request. The same goes for unicode support. Even if both say they support it, each message is flagged if it uses ascii or unicode strings. If only the server says CAP_UNICODE I suppose a client could send unicode strings and hope to get ascii responses. But servers seem to look closer at the flags2 than the negotiated bits, so I suspect it won't ... /Urban
Re: smbmount with big file sizes
On Thu, 11 Jul 2002, root wrote: But during boot time i gets some error message of this kind. # /lib/ext3.o: unresolved symbol iget4_R7414451b ... ERROR: /bin/insmod exited abnormally! # Is this ok? or i have missed out something. When you rebuilt your kernel you didn't rebuild the ext3 support as a module (your old kernel had it as a module) and something changed with the modversions (the funny numbers after the symbol names). Rebuild the kernel with ext3 as a module, or if you built it into the kernel remove the ext3.o file. The maker of the distribution you use has probably more info on how to build a kernel that works in that environment and/or google for others that have built custom kernels on that linux flavour. I don't recognise having modules directly in /lib ... Nice to hear that the LFS part is working. /Urban
Re: Link less to smbmnt
On Mon, 8 Jul 2002, Andrew Bartlett wrote: This patch removes most of that - in an attempt to allow for easier verification of its security status. I would also (but not included in this patch) like to remove its use of includes.h (for the same reason), but I know tridge has different opinions on things like that. What do people think? It should also be done for smbumount (which btw is also meant to be made suid root to allow user umounts). I sent this patch with some smbmount stuff to samba-patches some days ago, but maybe that place is dead: http://www.hojdpunkten.ac.se/054/samba/smbmount-2.2.5-misc.patch.gz I didn't remove includes.h either. Speaking of smbmnt, the current RPM .spec files place smbmnt in /usr/sbin, but smbmount looks for it in /usr/bin (BINDIR). The above patch fixes that so it also looks in SBINDIR but the current rpms are wrong and won't work when smbmount is started from mount. (Recent mount's unset parts of the environment, PATH, LD_*, etc) /Urban
Re: smbmount with big file sizes
On Tue, 2 Jul 2002 [EMAIL PROTECTED] wrote: I have also tried: http://www.hojdpunkten.ac.se/054/samba/index.html with exactly the steps whatever they are: But no luck i have used kernel 2.4.16 and samba 2.2.2. You have probably not patched both the kernel and samba, rebuilt and reinstalled both. If either samba or the kernel you are using[1] is unpatched you will not get large file support. Also note that there is a 2.4.18 version available. I don't remember that anything changed from the 2.4.16 patch, but I do know that a lot of people have had success with the 2.4.18 one. /Urban [1] - There is a difference between using and have installed. You can have multiple versions installed but use the wrong one.
Re: FW: samba woes
On Wed, 26 Jun 2002, Christopher R. Hertel wrote: Johnston, Christopher (DCSA) wrote: what is that exactly? I am looking for a method to automount NT shares from windows to linux.. so my users can access their home directories.. The common way to do that *kind* of thing would be by using SMBFS. My *guess* (because I really have not spent enough time working with SMBFS) is that the problem you're seeing is that you want a user-context mount (that is, only the user who mounted the share should be able to see the share), but you can't get that with SMBFS. You can give only a single user access to the mount. But it will be visible to others (inaccessible perhaps, but visible). An autofs map for /home looking like this could be a starting point: username1 -fstype=smbfs,credentials=/etc/samba/cred1,uid=username1 \ ://server/share username2 -fstype=smbfs,credentials=/etc/samba/cred2,uid=username2 \ ://server/share ... I think the RH suggestion was something like this, but with a script that generates the map (see executable maps in the autofs docs). pam_mount is also sometimes mentioned for this kind of thing, mount things when people login based on their username/password. I don't know if Steve's CIFS VFS bypasses that. He just made it available last week, I think... I understand there are plans to support accessing as different users on a single mount, and that is relevant if you want to mount /home and not each of the subdirectories as well as if you want users to access each others dirs as themselves. But that's more the opposite of being invisible to other users. /Urban
Re: Oddity in port 445 behavior...
On Fri, 21 Jun 2002, Christopher R.Hertel wrote: The problem here is that W2K simply ignores the packet, so the client must decide whether to time-out waiting for a reply or to start sending SMBs before it knows if it got an error message back from the server. I am not sure what happens if it times out, but we have seen Windows behave strangely if it senses a delay. Perhaps the best way to handle this is to make the connection, try the NBT SESSION SETUP, if you get a response then go with it, if not then close the connection and try again without the NBT SESSION SETUP. Having a timeout sounds bad, everyone doing ssh tunnelling to port 445 on win2k will hit it. Would this work for non 139/445 ports? 1. Send the NBT SESSION SETUP, but don't wait for a reply. 2. Send the protocol negotiation request (or whichever comes first). 3. Wait for a reply. 4. If the reply matches (1) then wait for the reply to (2). Or just provide an option and let the user specify it. /Urban
Re: Large file size issues with Samba client.
On Thu, 20 Jun 2002, Brett Simpson wrote: I'm trying to access a Windows 2000 server share that has files 2GB using the Samba client 2.2.3 that comes with Redhat 7.3. It lists the files as being many times larger than their actual size. I upgraded to the CVS version of Samba today and it still has the problem. Any ideas on how to work around this? Apply the 2.4.18 kernel patches from: http://www.hojdpunkten.ac.se/054/samba/index.html 00 - 02 + the samba patch to make smbmount negotiate. smbfs did not implement LFS before. /Urban
Re: CIFS VFS posted
On Thu, 20 Jun 2002, Steven French wrote: Good question - at some point I need to look at that. Clearly the structure is quite a bit different between the two. Most visibly the mount ... specification. Over time function between the two will probably diverge quite a bit more.I wanted to be much more aggressive in adding function and in design risks in the cifs vfs (ie more aggressive than I guessed we would be able to do in the smbfs which people rely on today to be stable) e.g. in adding function such as access control and Kerberos integration. smbfs does the ActiveDirectory kerberos thing already, even if I haven't let the patches out yet because of some silly mapping bug. It needs 32 bit error codes and a flag in smbmount (and possibly a connection to the kerberos tools/libs to refresh tickets for long-time mounts). I saw the mention of a future userspace helper, if you do that why not reuse samba code for other (non-performance critical) things such as connecting? smbmount is backwards, it should be mount that mounts smbfs and then smbfs calls back to smbmount (smbconnect). I have some rough patches for that too. Using net use to mount seems like a really bad idea to me, but maybe that was just for getting connections? smbfs used to have the connect code inside the kernel. I think someone was tired of copying work from samba and fitting it into the kernel when the current smbmount was done. That is a difference, but I'm not sure why it's an improvement over smbconnect. To me the structure of the code isn't all that different. Although there are some differences in what is supported, I find that to be more on the level of where work has been done than some fundamental design difference. Some examples: If you look at the current in-kernel smbfs code it is totally single threaded within one mountpoint (I think that dates back to when the kernel itself was single threaded), and that alone makes it a lot different. But if you have taken a look at the current work in progress you would see something that resembles the demultiplex_thread. The smbfs variant is called smbiod and is responsible for all network IO including oplock breaks, which is why it exists in the first place. This also brings alloc_request, which is similar to the allocations smb_init() does, and smb_rput which matches the buf_release() calls. That makes the locking requirement similar, and we have the ability to do multiple parallel smb requests. smbfs supports mmap and does all I/O through the page cache. This limits reads and writes to the page size (typ. 4k) but the readpage code allows it to plug into the kernel's readahead code (with an async version that's not been written yet). Readahead will allow merging requests into larger chunks. Unless I'm missing something cifs vfs does not support mmap or any caching, and does read/writes directly to the userspace buffer. But to support mmap you need to implement readpage and friends, which I believe will limit read/write to work on page size blocks. DFS support isn't available in smbfs. Although I haven't checked all the details of the cifs vfs support it seems to use one mount for each referral which is how I have thought about doing it in smbfs too. (Is dfs working in this version of cifs vfs?) cifs vfs stores fileid in the file struct, making each local open do one open on the server. smbfs stores the fileid in the inode and does one open to serve all it's local clients, instead counting the open/release calls. I believe this is also an old design decision in smbfs, but it's certainly not unreasonable to change and it is under consideration esp for the fcntl locking support. Having the server only see one file open may help when trying to make smbfs behave like some programs expect when more than one program accesses the same file locally and possibly with caching. It seems to complicate things in other cases such as when you do fcntl locks. ACLs, multi-user mounts, signing, quotas are all more or less unknowns to me so I can't comment on what those would require of smbfs. Maybe there are reasons why those would be a lot harder to support in smbfs than from the current cifs vfs base. In the 2.5 kernels you can temporarily break anything you want :), so disrupting current users aren't that much of a problem. The only cost of breaking things is all the questions it generates. /Urban
Re: Large file size issues with Samba client.
On Thu, 20 Jun 2002, Steven French wrote: FYI - The CIFS VFS handles large files and has been tested with RedHat 7.3 version of the kernel. It was a pain to test due to the lack of sparse file support on the Linux side (I had not seen an equivalent to the sparse flag on the Linux side - but it sure helps on the Windows side in creating test files). What lack of sparse file support? $ dd if=/dev/zero of=aa bs=512 count=1 seek=1024 1+0 records in 1+0 records out $ d aa -rw-rw-r--1 puw puw524800 Jun 21 03:26 aa $ du -h aa 8.0kaa There is no flag because it is always supported (given filesystem backing, and all unix-like filesystems support it). Just truncate it to the size you want it to be. /Urban
Re: 2.2.5pre1: unlink design flaw
On 13 Jun 2002, Simo Sorce wrote: And samba is not the only application that do this kind of operation, the proper fix would be to make smbfs driver able to hide a file if it is unlilnked but yet open by some process, and then silently unlink it when the last process closes it. It just involves a per open file counter and some kind of magic on directory listing/file opening. I have thought about this before. It doesn't fix everything, but maybe it helps for Jochens problem. One problem with hiding is that the file should remain open on the server: fd = open(aa);Server returns fid 1234 unlink(aa); smbfs hides aa from all dir listings etc. read(fd, buf, 1); reads and writes aa write(fd, buf, 1); But if some program then does: open(aa, O_CREAT ...) The server will not create a new file aa because it already exists. So you'd have to return an error here or get into a mess of having multiple shadow files that would have to be created on the server sometime later. I have no idea what posix says about open and unlink, but I'm guessing if it's been unlinked it shouldn't prevent creating a new file (or dir). Of course the current smbfs behaviour isn't even close to posix(?) anyway, in the example above the read() will fail because the file is closed in unlink(). The other simple option is to fail the unlink because the file is open. /Urban
Re: Microsoft's Dfs
On Thu, 30 May 2002, Richard Sharpe wrote: Hmmm, I don't think that any do yet. I expect to be looking at smbclient and will try to put the code into libsmb, but that is still an issue for things like smbfs, I believe because of the amount of junk that might get dragged in. Regarding smbfs support (I have just browsed the SNIA(?) docs on that and don't know anything beyond they few lines I have read ...) On some operations trying to access a directory which is really on a different server (or share?) an error code is returned, right?. What smbfs could do then is simply to mount that other directory on itself (would work sort of like autofs or maybe even with the help of autofs). To connect to the other server smbfs would call on smbmount and the amount of junk needed in kernel space would be kept to a minimum. But maybe there is more to dfs than that. I have however no immediate plans to do this. Also, if cifsfs when released is better than smbfs (faster, more stable, with dfs support, etc) it should replace it and work on smbfs features would be a waste of time. There was some comment on this list that the source for the cifsfs module would be made available on the samba ftp. Is it now? /Urban
Re: Microsoft DFS and the CIFS VFS
On Thu, 30 May 2002, David W. Chapman Jr. wrote: That makes sense. Currently we ship with something under GPL in our kernel so I think this has already been taken care of. We do not charge for our sources and they are all readily available. smbfs is distributed with FreeBSD and I believe that is under GPL. I think this module would be in the ports system though and not distributed with freebsd in a release. There is a smbfs implementation in BSD, but I believe it does not have any connection to the GPL'ed Linux version, other than for some comments where they have obviously compared what the code does (but that is allowed). I think it was made for one BSD variant first and that it has been copied to the others. Maybe that is why it is in 'ports'. /Urban
Re: file size limit smbmount
On Mon, 27 May 2002 [EMAIL PROTECTED] wrote: There is a limit of 2 GB when I copy a file (greater then 2 GB) from an Ext3 file sytem to a mounted smb share with smbmount. I got the message file size exceeded Upgrade your kernel to 2.4.18 and apply the 2.4.18 patches from this page: http://www.hojdpunkten.ac.se/054/samba/index.html Or upgrade to the latest 2.5. You also need to get the negotiation patch from that page and apply that to samba. Tested with 2.2.3a and I think it still works with 2.2.4. /Urban
Re: smbmount segmentation fault
On Thu, 23 May 2002, Marco Tizzoni wrote: Unable to handle kernel paging request at virtual address c800 Strictly speaking not a samba-technical issue (linux-kernel because it is about the linux kernel or samba because tridge put that list as the list for smbfs questions). The thing that crashed, at least initially, was probably not smbmount but ls. This patch should fix your problem: http://www.hojdpunkten.ac.se/054/samba/00-smbfs-2.4.18-codepage.patch.gz Or just move on to 2.4.19-preX Call Trace: [c0146280] [c8aa32a4] [c0146280] [c8aa4328] [c0146280] [c0146280] [c0145e29] [c0146280] [c014642f] [c0146280] [c01261e5] [c01070eb] Code: 0f b6 06 49 46 89 c2 c1 e8 04 c1 e2 04 8d 14 1a 01 c2 83 f9 And normally you are supposed to run these through ksymoops because it is impossible to know what function is located at 0xc8aa32a4. /Urban
Re: SMB Connection failed
On Thu, 23 May 2002, Abdij Bhat wrote: This was working fine a few weeks ago when we were using the full blown Red-Hat distribution built for our embedded target (MIPS). Now we have scaled down the linux to minimal files ( to fit to our flash ) and i beleive something is missing; which causes the problem. If it works on a std dist then maybe it is in the scaling (and since you apparently didn't get my tiny-smbmnt patch that can't be it). MIPS == big endian, no? Maybe that is your problem. It would nice if you could verify that smbclient gives a similar error as smbmount. If it doesn't then it's probably something smbmount doesn't do right. /Urban PS. How about picking one list that you think fits the problem best?
Re: smbmount
On Mon, 20 May 2002 [EMAIL PROTECTED] wrote: I'm having some trouble with smbmount. When I attempt to mount a share and specify a uid of 95829 it mounts, but gives it a uid of 30293 is samba limited to a 16 bit number the uid field? As promised here are the patches. It works for me but I don't actually need 32bit support so my testing of this isn't worth a whole lot ... For samba: http://www.hojdpunkten.ac.se/054/samba/samba-2.2-smbmnt.patch (diff is vs a recent SAMBA_2_2 checkout, but should be ok vs just about any samba 2.2.x release). For smbfs: (ie the kernel sources) http://www.hojdpunkten.ac.se/054/samba/smbfs-2.4.18-uid32.patch (should also be fine with 2.4.17 or 2.4.19-pre-something) You need to apply the patches and rebuild+reinstall both components. Samba: cd /foo/samba*/source ; patch -p0 samba-2.2-smbmnt.patch Linux: cd /foo/linux ; patch -p1 smbfs-2.4.18-uid32.patch If you are using 2.4.18 you should also apply this to be safe: http://www.hojdpunkten.ac.se/054/samba/00-smbfs-2.4.18-codepage.patch.gz 2.4.17 or 2.4.19-preX are ok without it. It does not conflict with the above and is totally unrelated. Just a bugfix for something someone else added far too late in a release cycle ... Let me know when you have tested this so I can send the patches to the respective source trees, or if you decide not to test them. If you have trouble with (applying) the patches we can handle that off-list. /Urban
RE: smbmount
On Mon, 20 May 2002, Esh, Andrew wrote:
But it gets assigned to data.uid in client/smbmnt.c, main(228):
data.uid = mount_uid;
This is where the info is lost. smbmnt needs to be changed not to use the
smb_mount_data struct as a storage for anything, it should only be used
inside do_mount iff it is on a 2.2 system.
... data_uid is defined like this in /usr/include/linux/smb_mount.h:
struct smb_mount_data {
int version;
__kernel_uid_t mounted_uid; /* Who may umount() this filesystem? */
__kernel_uid_t uid;
__kernel_gid_t gid;
This struct can't change because it will break old smbmounts. But it is
also no longer used to pass the information to smbfs on recent systems
(see do_mount) so that's ok.
It is possible to play with the version field and define a new struct, but
there is no reason for being different from most other filesystems by
sending this in a binary format in the first place.
Unfortunately smbfs uses a similar struct to keep the data so that needs
fixing too.
In the kernel source tree edit struct smb_mount_data_kernel in
include/linux/smb_mount.h and change:
__kernel_uid_t - uid_t
__kernel_gid_t - gid_t
__kernel_mode_t - mode_t
Done.
uh oh. Looks like a Linux smbfs problem. Did someone forget to update it for
32-bit IDs?
Someone added ioctls for returning 32bit uids but probably didn't test if
the whole chain worked, with the interface to samba and the code in the
samba tree.
It's getting kind of late over here. I'll post patches tomorrow if no one
else does it first.
/Urban
Re: smbmount, smbumount and smbmnt
On Tue, 30 Apr 2002, Abdij Bhat wrote: Hi, I am deploying samba for an embedded system. The requirement is that the system should be able to mount windows share points. I believe smbmount, smbumount and smbmnt components are needed to do the same. I am not very clear about smbmnt though! I find that smbmount, smbumount and smbmnt are all quite huge. Around 300 to 400Kb each. smbmnt is linked with libsmb even though it doesn't use anything from it. It is possible to make it much smaller by editing the makefile. I have a patch if you want. smbmnt exists to allow parts of the code to be setuid root for normal user mounts and is run by smbmount. smbumount is only needed if you need normal users to mount and umount things. root can umount with the normal umount command so you could just remove it. smbmount only uses a few parts of libsmb directly, but there are a lot of dependencies between different parts of libsmb. Also whenever i choose SMB_FS support in the Kernel configuration, i am forced to choose the NLS. Do i really need it? How can i do without it? Also If you don't enable any of the kernel codepage modules, nothing extra will be built. If you don't enable CONFIG_SMB_NLS_DEFAULT then smbfs will not use any nls code. the smbmount demands codepage.850, codepage-def.850, unicode_map.850, unicode_map.ISO8859-1 files. I have not provided the same in my embedded development environment. Funnily, although it complains that the above files Those are samba codepages and the smb.conf controls which ones to use, with these being the defaults(?). /Urban
Re: /etc/fstab entry to allow users to mount samba shares
On Tue, 23 Apr 2002, Lars Heineken wrote: I'm sorry to tell, but I Had to drop the whole thing. When I mounted the volume as root, a single read-acces onto the mountes smb-share on the client-side locked his machine. The smb-server noticed nothing. The cd-rom is mounted via supermount. All windows-clients read the share without problems. - Suggestions ? Reasons ? Does it make any difference if you don't use supermount? Kernel version? That the client locks is a bug, but it's not necessarily possible to make it work well with a server that replaces the contents like a cd being switched. A try with nfs showed other problems. With nfs I couldn't mount /mnt/cdrom. This worked after explicit mounting of /dev/cdrom, supermount disabled. I think the kernel prevents sharing of supermounted directories. Reading about it, I get this feeling that supermount isn't supported. Manually mounting and exporting as nfs sounds better, but that may cause problems for the windows clients if they don't support it + the manual mounting needed. There is a hack called volumagic that you could play with. It is in proof of concept state, so be happy if it works: http://ftp.linux.org.uk/pub/linux/alan/Software/System/Volumagic/ It's like supermount, except it uses some 2.4 kernel features to work better. At least that's what the commercials say. Using autofs on the server with samba may never umount the cd and then you can't switch it. There is a --with-automount flag when compiling samba, but I don't know what that does. /Urban
Re: /etc/fstab entry to allow users to mount samba shares
On Tue, 23 Apr 2002, Lars Heineken wrote: I tried to make an entry in /etc/fstab to enable users to mount a specific samba-share (here: //Heineken/CD-ROM) //Heineken/CD-ROM /mnt/HeinekenCDROM smbfs user,auto,username=x, passwordx0 0 the only way to make this work is that the mount-destination is owned by the user who want's to mount. So lars for example can do the mount if /mnt/HeinekenCDROM is owned by lars. As I don't want a speparate mountpoint for each user, how can I solve this the right way. Just like a CD-ROM mount ? The right way is to throw away smbmount and use smbconnect. The problem you are seeing is that mount reads the fstab but doesn't do anything with the entries and just passes them to smbmount. smbmount then does the mount syscall that mounts smbfs, but it doesn't (want to) understand the options mount has and interprets them differently (eg user). smbconnect would mean that mount does the mount syscall, and also all the user/auto/noexec parsing so it would be identical to all other fs'. smbfs then calls smbconnect to get the connection. The only problem with this is that smbconnect only exists on one of my machines and is not very well tested. There are a few other options that may be seen as less experimental: * automount Use autofs or some other automounter. Judging from the mount options you don't care if a user can access the cd some other user mounted. With autofs the following: /etc/auto.master: /mnt/heineken /etc/auto.heineken --timeout=60 /etc/auto.heineken: cdrom -fstype=smbfs,username=x,password=x ://Heineken/CD-ROM would mount the cdrom when someone tried to access /mnt/heineken/cdrom. A potential problem might be what happens when the cd is ejected on the other end. I know I have never tested that ... * setuid root mount_heineken_cdrom Another way to do this is to make a small setuid root program to do this mount. For safety all options should hardcoded into the program. * modify smbmnt The rule that only the user may mount on dirs he owns is implemented in smbmnt. You have the code, change it. Do note that it is a security risk to let users mount things wherever they want ... /Urban
