Windows shares from Linux -- concurrency, autofs?

I'm a Linux user in a Windows world. Need to access Windows shares (which are used copiously, with many shares on many servers -- something like 270+ on the LAN).

\r\n\r\n

I messed around this morning to come up with a script to identify all servers and shares, the guts of it are:

\r\n\r\n

\r\n

\r\n# List available servers (and other stuff, cut down with sed later)\r\nsmbclient -U ${user}%${pass} -L $domainserver\r\n\r\n# For each server above, list out the shares (this is iterated over a list)\r\nsmbclient -U ${user}%${pass} -L $SERVER\r\n

\r\n

\r\n\r\n

Using this, I created mountpoints and /etc/fstab entries for each share.

\r\n\r\n

I then created another script to mount all shares on a given server. That's where the trouble starts.

\r\n\r\n

\r\n

\r\nfor mp in $( find /net/qpc/$SERVER/ -maxdepth 1 -mindepth 1 -type d )\r\ndo \r\n    if ! grep -q "$mp " /proc/mounts; then\r\n        echo -e "$mp...\\c"\r\n        mount $mp && echo "mounted" || echo "FAILED"\r\n    else\r\n        echo "Hmm...  Looks like /net/qpc/$SERVER is already mounted"\r\n    fi\r\ndone\r\n

\r\n

\r\n\r\n

...which, for a given server might range up to 32 shares. I can only mount a maximum of ten in one instance. Attempting to mount others results in the following error:

\r\n\r\n

\r\n

\r\n/net/qpc/SERVER/SHARE...7436: session setup failed: ERRDOS - 71\r\nSMB connection failed\r\nFAILED\r\n

\r\n

\r\n\r\n

Worse: attempts to access the server (not merely the share) from Win2K also fail. So the concurrencies are counting against Windows users as well. What happens when we get eight workstations accessing the same share I don't want to know....

\r\n\r\n

Single user access from Windows doesn't seem to count against this though. Grabbing 16 folders from a server and popping them all open does work. So there's something about mounting from Linux which counts as a concurrency -- even as a single user from a single system, all under the same Windows user ID.

\r\n\r\n

Anyone got the skinny on the source of the restrictions, what we might need to look out for in the way of Windows use (this is our production data, and it's not inconceivable ten users could want access at some point), workarounds for Linux, or alternatives (I'd love to see a huge-ass whompin' Linux samba server here, but...). For the Linux workaround side, using autofs to access the shares on an as-needed basis would be ideal, I've looked into this briefly.

/etc/auto.master points the autofs mountpoint to /var/autofs/misc. /etc/auto.misc specifies what remotes get automounted to what subdirectories (flat space, no submounts) of /var/autofs/misc. Typical line, to mount my Win2K cygwin root as /var/autofs/misc/SELF_cygwin is:

\r\n\r\n

\r\n\r\nSELF_cygwin -fstype=smbfs,noauto,credentials=/root/samba_creds,workgroup=DOMAIN1, gid=smbuser,fmask=660,dmask=770 ://SELF/cygwin\r\n\r\n

\r\n\r\n

(That should be one line).

\r\n\r\n

To make things slightly handier, I've created a directory under /net listing servers and shares explicitly, so /net/SELF/cygwin might point to \\SELF\\cygwin. This provides more context for traversing directories.

\r\n\r\n

I've also set the automount timeout in /etc/defaults/autofs to four seconds, to avoid the resource starvation issue mentioned above. Could probably be set lower.

\r\n\r\n

The whole getup seems to be working relatively well. Docs indicate some ways for doing "submounts" which seems the handy way to organize hierarchical structures such as server/share combinations. Not to mention not having to keep sets of links and autofs hints up to date. I can script same, but that would get tedious fast.

Welcome to IWETHEY!