Subject: Re: CIFS and rename of open files - msg#00061

Previous Message by Date: click to view message preview

Re: Mounting OS/2 shares with cifs

On Mon, 21 Jul 2008 11:15:24 +0530 Suresh Jayaraman <sjayaraman@xxxxxxx> wrote: > Jeff Layton wrote: > > On Fri, 18 Jul 2008 14:52:17 +0530 > > >> > >> smbfs has been obsoleted and slated for removal as it has been replaced > >> by cifs. But as I understand cifs is unusable with OS/2 shares. Some > >> customers who had been using smbfs to mount OS/2 shares for a long time, > >> think this is regression introduced by cifs over smbfs and their > >> installations are going obsolete. > > > >> Given that there is a considerable userbase, do we have a plan to > >> support mounting OS/2 shares? I would like to hear what is the > >> community's take on this? > >> > > > > This should work with current CIFS, but you'll need to build the > > client's kernel with CONFIG_CIFS_WEAK_PW_HASH enabled, and enable > > LANMAN passwords in SecurityMode. OS/2 doesn't support anything more > > secure than LANMAN passwords, AFAIK. > > > > Yes, with these options enabled I guess users are able to mount and > navigate but are hitting -EOPNOTSUPP during open/write. > > Any idea what is missing? > Not right offhand. I'd probably start looking at network traces and cifsFYI output... -- Jeff Layton <jlayton@xxxxxxxxxx>

Next Message by Date: click to view message preview

[PATCH] cifs.upcall: fix compiler warning and some usage typos

Steve French noticed these warnings when building cifs.upcall: Compiling client/cifs.upcall.c client/cifs.upcall.c: In function 'usage': client/cifs.upcall.c:204: warning: declaration of 'prog' shadows a global declaration client/cifs.upcall.c:33: warning: shadowed declaration is here Change the usage function to not take and arg and have it just use the global "prog" variable. Fix a typo in the log message generated when an unknown option is specified. Also getopt() always returns '?' when it sees an unknown option so there's no point in printing it out. Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx> --- source/client/cifs.upcall.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/source/client/cifs.upcall.c b/source/client/cifs.upcall.c index 3860f33..825870d 100644 --- a/source/client/cifs.upcall.c +++ b/source/client/cifs.upcall.c @@ -201,7 +201,7 @@ int cifs_resolver(const key_serial_t key, const char *key_descr) } void -usage(const char *prog) +usage(void) { syslog(LOG_WARNING, "Usage: %s [-c] [-v] key_serial", prog); fprintf(stderr, "Usage: %s [-c] [-v] key_serial\n", prog); @@ -234,7 +234,7 @@ int main(const int argc, char *const argv[]) goto out; } default:{ - syslog(LOG_WARNING, "unknow option: %c", c); + syslog(LOG_WARNING, "unknown option"); goto out; } } @@ -242,7 +242,7 @@ int main(const int argc, char *const argv[]) /* is there a key? */ if (argc <= optind) { - usage(prog); + usage(); goto out; }

Previous Message by Thread: click to view message preview

Question about CIFS versus smbclient.

(I've tried to post this message on the cifs-protocol list, but now I know it's not the best place for this. Sorry about that)Hello,One of the things is the creation of a autofs managed networkmountpoint. This construction creates a mountpoint in the homedirectory of a user ("Global Network" it is called here), where an automountpoint is. The automounter maps a script here, which output is a multi mount map. The automounter makes a browseable tree with it, representing the "network" environment./home/sbon/Global\ Network     /etc/autofs/session/auto. network.sbon -browse The script auto.network.sbon generates a multi mount map, when the key is the name of the network. For example:-----root [ /etc/autofs/session ]# ./auto.network.sbon "Windows Network"-fstype=cifs,credentials=/home/sbon/.autofssession/smb/mount.cred \ /BONONLINE/LFS20060812/bononline -rw,ip=192.168.0.2 ://LFS20060812/bononline \/BONONLINE/LFS20060812/ftp -rw,ip=192.168.0.2 ://LFS20060812/ftp \ /BONONLINE/LFS20060812/sbon -rw,ip=192.168.0.2 ://LFS20060812/sbon \/BONONLINE/LFS20060812/video -rw,ip=192.168.0.2 ://LFS20060812/video \ /CWWERKGROEP/ROUTER/cwdocumenten -rw,ip=192.168.0.1 ://ROUTER/cwdocumenten \ /CWWERKGROEP/ROUTER/public -rw,ip=192.168.0.1 ://ROUTER/public \/CWWERKGROEP/ROUTER/sbon -rw,ip=192.168.0.1 ://ROUTER/sbon (in my network there is one workgroup (cwwerkgroep) with one server (router), and one domain (bononline) with one server (lfs20060812). the script reads this data from locally maintained cache build with utilities nbtscan and smbclient)So when accessing the "Windows Network", the automounter gives the user a browseable tree, and when accessing a share, it's mounted automatically, with cifs. (not only windows network is supported, but also FTP and SSH, with the help of Fuse modules sshfs and curlftpfs) More information about this:http://linux.bononline.nl/linux/automountsmbshares/automountsmbshares- page01a.php Now, I've asked the Dutch magazine "Linux Magazine" wheather I can write an article about this, and they do agree!!  Houra! But it should not be to technical (no howto!), and only give an overview of the advantages of this construction compared to the methodes used in the desktops like KDE (with kio_smb) and Gnome (with Gnome VFS and the smb module). These methodes are based upon the smbclient library. Now, when starting the article, I find it difficult to summarize the pros of this construction (and in particular the use of CIFS versus the library libsmbclient.so). I know that a Samba server (with unix extensions enabled) or a Windows server (also with unix extensions) does provide information about user and owner, and the mode.Smbclient does not do anything with it, where CIFS does report those transparantly.Futher, connections based upon smbclient, are not really mounts. Intuitive I can say that that is a big disadvantage, compared to connections based upon CIFS, but I cannot really make it concrete. I've read a about POSIX compatablilty, but I'm afraid I do not really understand the benfits.Can you help me here?The benefits are obvious when used with a Linux Samba server. In combination with NSS nameservices like Winbind and/or OpenLDAP to make use of the same accounts as the server does, it works very good.What benefits are there when used in a pure Windows environment? If the Windows server does not support the Unix extensions, CIFS is not able to report the UID/GID and the mode. This behaviour is much like the smbclient way of doing.Hope you can help me,looking forward to your reaction,Stef Bon _______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client

Next Message by Thread: click to view message preview

Re: CIFS and rename of open files

On Tue, 22 Jul 2008 00:44:14 +0200 Wilhelm Meier <wilhelm.meier@xxxxxxxx> wrote: > Am Montag, 30. Juni 2008 schrieb Jeff Layton: > > On Wed, 25 Jun 2008 09:52:23 +0200 > > > > Wilhelm Meier <wilhelm.meier@xxxxxxxx> wrote: > > > Hello Jeff, > > > > > > Am Freitag, 6. Juni 2008 schrieb Wilhelm Meier: > > > > Am Freitag, 6. Juni 2008 schrieb Jeff Layton: > > > > > On Fri, 6 Jun 2008 10:49:26 +0200 > > > > > > > > > > Wilhelm Meier <wilhelm.meier@xxxxxxxx> wrote: > > > > > > Hello, > > > > > > > > > > > > are there any news to the issue of renaming open files - > > > > > > because this missing feature is preventing the use of cifs > > > > > > as user homes on linux systems. > > > > > > > > > > I was looking at the problem earlier this week, but haven't > > > > > gotten all the way to a solution. The issue is very dependent > > > > > on server behavior, with windows servers being particularly > > > > > problematic. I've been doing some experimentation, but > > > > > haven't found a solution that seems to work well for all > > > > > cases. > > > > > > is there any progess or activity from your side? I'm asking > > > because this is a show-stopper using cifs-homes for users with > > > newer kmail-versions. > > > Or do you know any workaround in this respect? > > > > I'm afraid that I've been sidetracked into other things and haven't > > had time to touch this. The problem is (I think) that CIFS > > currently tries to set the DELETE_ON_CLOSE bit using the create > > flags in the open call, but this only works if the file is actually > > being created. So we need to set the bit with a SET_FILE_INFO call > > and then try to rename it. > > > > I'm probably wrong on some of this though, this turns out to be a > > rather tricky situation to handle correctly, and it will probably > > take some experimentation to get it right. I don't know of any > > workarounds for this at the moment... > > Is there anything I can do in the combination of samba-server and > linux-cifs to prebent the problem? > Not that I know of. Possibly there are some server settings that can work around this, but I'm not certain. > Do you need a testprogram? If so, I would try to write one simpler > than kmail ;-) > A test program would be very nice when I (or someone else) gets an opportunity to work on this. Something like kmail is going to be far too complex to be useful. Thanks, -- Jeff Layton <jlayton@xxxxxxxxxx>