You are not logged in.
nmap <server>
Is the old server still online?
Offline
The test account is disabled, but the server is still online:
$ nmap 10.xx.xx.xx
Starting Nmap 7.80 ( https://nmap.org ) at 2020-02-05 10:45 CST
Nmap scan report for ceph-osd0.xx.xx.xxx.edu (10.xx.xx.xxx)
Host is up (0.29s latency).
Not shown: 993 closed ports
PORT STATE SERVICE
22/tcp open ssh
111/tcp open rpcbind
2967/tcp filtered symantec-av
3389/tcp filtered ms-wbt-server
4444/tcp filtered krb524
6129/tcp filtered unknown
6667/tcp filtered irc
Nmap done: 1 IP address (1 host up) scanned in 3.55 seconds
Offline
Neither 139 nor 445 are open on that server… ??
Offline
Sorry, that was the virtual machine server. Perhaps you meant the CIFS server.....
$ nmap ifs.xxx.xxx
Starting Nmap 7.80 ( https://nmap.org ) at 2020-02-05 11:01 CST
Nmap scan report for ifs.xxx.xxx (10.xx.xx.xx)
Host is up (0.24s latency).
Not shown: 984 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
135/tcp open msrpc
445/tcp open microsoft-ds
2049/tcp open nfs
2967/tcp filtered symantec-av
4444/tcp filtered krb524
6129/tcp filtered unknown
6667/tcp filtered irc
8080/tcp open http-proxy
8081/tcp open blackice-icecap
8082/tcp open blackice-alerts
8083/tcp open us-srv
15000/tcp open hydap
Nmap done: 1 IP address (1 host up) scanned in 3.08 seconds
You can see 445 is open on the CIFS server.
Offline
NetBIOS (139) isn't - can you check whether it was on the old server?
Offline
Just checked, 139 was not open on the old server.
EDIT: Just updating to note that the IT person was able to map the CIFS share to an NFS server, which I could access. We had to push my local user permissions down to the file tree to allow me rw access, but everything is now working as expected.
Not marking this solved, because the original problem (mount.cifs permission denied) still persists.
Last edited by zekebsatx (2020-02-10 18:53:13)
Offline
I don't know if the response is still interesting, but hopefully my issue helps you (the poster) ...
I was just experiencing failing smbmounts (via /etc/fstab + automount) although nothing had obviously changed on my arch installation.
After some playing around I found that the reason was my password.
It contained a ','-character. For quite some time this worked perfectly, but failed since yesterday.
From the dmesg entries I found mount.cifs reclaiming a wrong parameter, which was identical to my password part after the ','
Changing the password to one without ',' helped.
By the way, password has been within a credential file.
Maybe other special characters have some special meaning if sent to the server, which they hadn't before.
So, just try to replace all special characters by different ones (or better only numbers and letters, if your server allows that).
Just my 5 cts :-)
Bernhard
Offline
I don't know if the response is still interesting, but hopefully my issue helps you (the poster) ...
I was just experiencing failing smbmounts (via /etc/fstab + automount) although nothing had obviously changed on my arch installation.
After some playing around I found that the reason was my password.
It contained a ','-character. For quite some time this worked perfectly, but failed since yesterday.
From the dmesg entries I found mount.cifs reclaiming a wrong parameter, which was identical to my password part after the ','
Please do not necrobump unrelated threads.
The comma is probably the only problem. https://www.reddit.com/r/archlinux/comm … our_samba/
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline