Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I've been struggling with a problem I'm having with accessing a share located on a Windows 2000 Server box. Smbmount successfully mounts the share, but only about half of the folders are listed in nautilus. I try accessing the share through a terminal (with ls -al) and it says that there are no folders or files.
The share contains about 200 folders directly underneath the root of the share. SMB will access the share just fine if I decrease the amount of folders in the root of the share, but I don't want to modify my windows filesystem to get linux to see all the folders in the share. I've also googled and searched the smb documentation/bugs for this problem, and oddly enough I can't find a trace of it. I can't believe that no one else has had this problem.
Here are my specs:
Suse 9.2, w/ stock version of Gnome
Kernel ver 2.6.5
Samba-Client version 3.0.4
Command I use to mount the share:
mount -t smbfs -o username=my_win_username //server/share /local_mount_point
I've tried various logons, even the administrator account (with full control of all folders). It's the same every time. I've even tried resetting the share permissions to everyone->full control which doesn't work.
The only rights that should matter are the ones belonging to the user that I'm using to login to the share. I really doubt that it's a permissions problem, as I'm able to read/write files just fine. And, I can move the files which are visible out of the folder, and then the remaining ones (which didn't show up before) appear.
I've also tried other file managers (mc, gmc, kde, and a terminal window)...all of them besides the terminal window gives a partial listing of files. The terminal window simply shows that there are no files at all.
Distribution: Red Hat 7.3, Red Hat 9, Solaris8, Slackware 10, Slax on USB, AIX, FreeBSD, WinXP, AIX, Ubuntu
Posts: 418
Rep:
I guess you missed the point here... (Or i did...)
If you have different permissions on the (sub)folders on your windows machine, it doesn't matter if you use other clients whatsoever... It just still uses the same credentials...
Bare with me here:
You have a windows machine, with a folder AAA.
Folder AAA has NTFS userrights: UserA: Full Control
In this folder you have folders: XXX YYY and ZZZ
folder XXX and ZZZ have ntfs rights: UserA: Full Control
folder YYY has ntfs rights: OtherUser: Full Control
Now, you share folder AAA, with sharepermissions of UserA: Full Control, or even Everyone: Full control.
The effective rights are that everyone can connect to the share, but only UserA can actually access XXX and ZZZ.
OtherUser can access the share, and can access YYY, but not XXX and ZZZ.
So, are youre NTFS right in order (Not your Share Rights)?
(Maybe being a bit tutorish, but, right-click the folder, select properties, and then select tab Security, check this, or make clear you did check them!)
Well I think you just confused me more than ever as to what you were trying to say, but I'm telling you it's not a permissions problem. Permissions for the folder I'm sharing (as well as all of it's subfolders) have inherited permissions turned on from the root folder of the drive. Effectlively, the same permissions for all folders are set on every folder on this drive.
The reason I know for certain that it is not a permissions problem is because I can access all of the subfolders of this share without a problem using the same credentials on a Windows box. So logic tells me that it's a configuration issue with SMB on linux (or a bug).
By the way, no need to get into tutor mode. I'm an MCSE hehehehe (I probably shouldn't admit that on this message board, should I? ) so I sort of already know my way around windows security. Although If you have advice that points to linux, I wouldn't consider myself a novice by any means, but would probably need a bit more explanation on that front.
Also, aI didn't mention it before, but all in all, this share contains about 4,000 mp3 files (each album in a subfolder) and is located on a win2k domain controller. I don't know if any of that makes a difference to Samba or not, but I thought it was worth mentioning.
Distribution: Red Hat 7.3, Red Hat 9, Solaris8, Slackware 10, Slax on USB, AIX, FreeBSD, WinXP, AIX, Ubuntu
Posts: 418
Rep:
Whaahahahhaahhaaa, not to offend you in anyway (Or actually a well, just a little bit.. LOL) but what do they teach you these days if i just confused you more with this basic MSCE theory on how permissions on NTFS work???
I tried to explain that File/Folder priviliges are NOT the same as Share-priviliges...
Anyway, as i can assume you know your way in the M$ environment then, lets assume its a SMB problem...
Are the folders you cannot see through the smb-share visible from another windows machine?
Are there any specifics on these folders? Like very long names, special characters? Path exceeding 256 characters for example?
heheheh...I was just saying that the way you explained it confused me...that's all
Yeah, I have a really good grasp on the difference between share and ntfs folder/file perms. Actually, they test the heck out of that during the certification...one of the seven tests is devoted to windows security. With that, and the questions that they ask on security during the networking and OS exams, about half of the certification is devoted to security.
Anyway, there's nothing out of the ordinary about this share except for the amount of data in it. Appx 200 subfolders directly beneath the root of the share, containing approximately 4000 files. A total of about 40gb. The folders and files have pretty normal filenames (no special characters, none longer than say 20 characters, etc).
I've tried just about everything. On the windows front I've:
Mounted the share on a windows xp client using the same credentials (works fine)
Recreated the share with a different name
Looked for permission issues (as you already know hehehe)
Moved the folders that weren't showing into a second share. This allowed me to see those folders, but I want to be able to see them all in the same share, not two different shares.
On the linux front I've:
Upgraded to the latest version of the samba client
Tried mounting the share from a different linux box (same OS -- SuSE 9.2). Does the same thing.
Distribution: Red Hat 7.3, Red Hat 9, Solaris8, Slackware 10, Slax on USB, AIX, FreeBSD, WinXP, AIX, Ubuntu
Posts: 418
Rep:
Well, i guess my tutoring skills need some polishing then...
However, this is indeed a strange problem... Haven't seen it before, other then with the mentioned permissionproblems...
I will try to think of something usefull, but don't get your hopes up... There should be a reasonable explanation for it, but i haven't got it (yet)... If I manage to figure it out, I will let you know! (And if you figure it out, please write the solution here also ? )
Anyone with other suggestions, or the ability to figure this one out, please do so... Im not giving up, but this one goes a bit out of my league at the moment...
the only thing I can think of is that for what ever reason, the smb client hits a time out on querying the folder contents of the windows share so it only lists out the folders it finds before the timeout occured.
Check the Syslog or whatever the log smb uses. I'm sure the error is listed there.
Distribution: debian, gentoo, os x (darwin), ubuntu
Posts: 940
Rep:
you wrote you were using nautilus. rather than mounting the shares with the mount command try 'browsing' to smb:/// or smb://server or smb://server/share
also: upgrade to latest stable versions of your samba clients (and nautilus)
if all still fails, do a step by step setup, starting of with creating a new share on your windows box, and rather than just copying files across, create the subdirs manually (or try sharing a fat partition)
i am not all that familiar with shares on windows, but from linux to linux using samba i know that the mount command will not actually mount the share but the filesystem! (also the reason why i wrote to try smb:/// 'cause this will brouse the share)
nicer idea still: use ssh to copy everything to your linux box, and setup the shares from the other side - this eliminates any windows errors :-)
I actually have tried brousing via nautilus using smb:// and this does show all the folders. Unfortunately, when I double click a file to open it, it gives an error saying it can't open files located on SMB shares. That leaves me with an option of mounting the share (which we know doesn't work) and with copying the files directly.
I guess this tells me that it is a problem with the way my kernel handles ntfs rather than a SMB problem. I have no clue about what ntfs support is compiled in, because it's a stock kernel. Does anyone have any clue what modules I would need to compile into the kernel for the proper NTFS support? No need to explain the kernel recompilation process...I've got that one covered
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.