Might be a rights issue. Have a look at the security settings on the physical .mdf file and make sure the user you are using for SSMS has access to that .mdf file.
Most probably, as you are supplying credentials, you are logging on with your Windows user id, so make sure that you have read-write priviliges on the .mdf file.
To get to the security settings:
Explore -> Locate your file -> Right click -> Properties -> Security Tab
Your user group or your user should be in that list.
If you are running the GUI on the same machine as the mssql-server service, then you can use localhost for the address (127.0.0.1). If you are running the GUI from a different workstation, you'll need the IPv4 address of the machine where the mssql-server service is running. You can obtain that by running ifconfig
from a Linux terminal prompt. Sample output from ifconfig
:
eth0: flags=4163 mtu 1500
ether 00:15:5d:89:45:01 txqueuelen 1000 (Ethernet)
RX packets 423 bytes 137827 (134.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth1: flags=4163 mtu 1500
inet 192.168.200.11 netmask 255.255.255.0 broadcast 192.168.200.255
inet6 fe80::2f70:9d15:8e7d:16cb prefixlen 64 scopeid 0x20
ether 00:15:5d:89:45:04 txqueuelen 1000 (Ethernet)
RX packets 20138 bytes 2006000 (1.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 19756 bytes 30125657 (28.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1 (Local Loopback)
RX packets 3239 bytes 361340 (352.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3239 bytes 361340 (352.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
In the output above, the bit that is important is the "inet" address, which in my case is 192.168.200.11.
The default port for SQL Server is 1433 - unless you chose a different port in mssql-conf use that port number. Ensure the firewall on the Linux box is allowing outside connections via 1433, if you intend to connect to SQL Server via the network.
Use sa
as the login, and the password you specified during SQL Server setup via the sudo /opt/mssql/bin/mssql-conf setup
command.
I would leave the domain and unix socket path blank.
Once you have connected to the instance, you may want to configure a non-sa account. Do that with the CREATE LOGIN
statement.
Just an FYI, you can use SQL Server Management Studio to connect to SQL Server on Linux, if that's your desire. Alternately, you can download Microsoft's native GUI client for Linux (and Windows & Mac), Azure Data Studio, here.
Best Answer
The connection information suggest the SQL instance is simply a local SQL Server instance installed in the VM like any other software so you don't use the Azure portal to manage it. Instead, ssh into the VM and run
systemctl status mssql-server --no-pager
to see if mssql-server.service is listed.The instance could also be a docker database container, in which case you can use
docker ps
to list the docker containers running on the machine.