I have a friend with an office in his house that has been using a box with win2k pro as an in-house file server for quite a while and with literally zero problems the entire time since I made that for him.
Its h/w was updated a couple of years ago and it just keeps going fine - and I will be replacing it with a Linux box sometime in the future for him.
There is just him, a secretary & a part-time assistant, a total of 3 other PCs that share files via the server (which is not accessible via internet at all).
I just replaced his desktop PC with an Ubuntu Mate 18.04 box that also has a VM of his previous XP system for his specialised s/w to stay in use & most everything is fine, but...:
Samba refuses to play nice with the shared stuff on the win2k pro server.
With or without credentials it will not gain access - though the windows network is visible to it, and it uses the 2 windows network shared printers, the Samba logging in fails every time such that he has no more direct access at his PC to his own files while using the host OS.
What is really puzzling about this happened when the VM of XP fired up & already had ALL of his shares from the server active & perfectly accessible with zero hesitation.
All the network protocols are active on the win2k box & I've tried every Samba trick that I have been able to find via searching without any success.
I also looked around here & followed the suggestions before posting this query=>
And:
I have not yet had the chance to try every single suggestion made in those 2 replies, but I will try more ASAP to get this to work.
In the meantime:
I am hoping that someone else here has run into this problem & has some sort of a definite workaround for it ??
Simply replacing the win2k box will be my best option, I know - but sadly ATM my biggest problem is in getting there again anytime soon - as I am over 100 miles away with no car at present, so I need to do what I can via remote, if possible.
If I understand the setup, on the w2k system create a folder c:\shared, share it with everyone, R/W.
On any of the linux systems for the 3 employees, they should be able to use caja and open location ... smb://w2k-ip/shared and read/write in there. I assume all systems (linux and w2k) are on the same subnet. If you want different login credentials for each employee, it needs a bit more work.
I quickly spun up a similar replica of this setup in a virtual environment - a Windows 2000 computer sharing a folder share from an Ubuntu MATE 18.04 client.
It might be down to "too strict" or "too vague" permissions by either the server or client, especially with the vast version differences between the server and client. Even Windows 10 doesn't find SMB1 shares without explicitly enabling it these days.
What I did on the server:
Create a folder on the desktop, shared this as "hello".
Created a user called "test" with password "1234" and gave the user access like so:
What I found was:
I couldn't see the computer in "Browse Network", but directly connected via smb://<ip address>/<share name> just fine.
I could login as the "test" user to view available shares at smb://10.0.2.15/ but it couldn't open the "hello" share.
To access the "hello" share, I needed to go to the "Security" tab and grant the same "test" user access to the share.
The connecting user needs a password or the share doesn't open. Note that connecting passwordless was fine from a Windows XP client.
I couldn't get "Anonymous login" to work without the login box constantly appearing / hanging.
So, if you've got remote access to the server, it may be worth double checking the security / sharing permissions are set up correctly, or introduce a dedicated user if everybody has been connecting anonymously up to now.
Thank You - Thank You - Thank You Lah7 for this amazingly helpful & wonderful reply !!!
I will try what you found momentarily, and it occurs to me to ask this:
The server share has a bazillion subdirectories with client files - will EACH thing need its permissions changed, or can I use 'advanced' for all of that stuff to inherit the perms automagically - do you know ??
OK, good news to share !!
My curiosity was ignited by the whole SMB1 problem, so I dug into that a bit while waiting for my remote access time to arrive today...fascinating too - disappointing, but still, it worked out well for this problem/solution.
Early on I found this:
And sure, it is for other than file sharing - but the info seemed applicable, so I tried it.
So when my access time arrived, I tried it, and...
Still, problematic, but I'd also found this:
Which includes (after where it says 'UPDATE':
Create target directory to mount remote share:
sudo mkdir -p /mnt/my_mount_dir
sudo mount -t cifs -o "domain=MYDOMAIN,username=MyUserName,password=myPas$werd,sec=ntlm,vers=1.0" (your windows host ip)/(your remote share name) /mnt/my_mount_dir
I also ran across some mentions of SMB & FUSE, which looked interesting, but I didn't follow them.
Now I have very careful notes & will be monitoring the situation closely myself - while of course my friend is very good about hollering to me when there is any trouble, so its all good, for the moment.
It might be down to "too strict" or "too vague" permissions by either the server or client, especially with the vast version differences between the server and client. Even Windows 10 doesn't find SMB1 shares without explicitly enabling it these days.
