Yet for the mac users browsing the qnap can be incredibily slow while the PC VMs that i have on a host there can access without issues. I can connect to SMB from our Main office over the VPN without any lag or issues. Thumbnails can be slow to show but i am remote. I went into the advanced setting of the win/mac/nfs and enabled asynchronous I/O ( qnap has one PSU going into seperate UPS) I enabled SMB v3.0 last night but currently everyone is using afp. Restarted and reviewed Switch and Port LACP setup and it looks and works fine from PC. Reviewed Nic on qnaps and there are no errors. Reviewed Port details on the switch and there aren't any errors One thing to note is initially we tried to setup spotlight to index the nas but it didn't work so we diabled it and tried Fox Trot search. I'm not sure what else i could be missing or where the root cause is. IN a nutshell, its Apple's half hearted implementation of SMB. But this is basically how SMB authentication works "under the hood", and if you need to deal with old versions of Samba, it might be useful still.Have a look at SMBup, I have an office with 10+ Macs, connections were a disaster until we ditched the built in SMB engine. (Newer versions of Samba may have a built-in check for this specific situation, and they might allow you access nevertheless. Otherwise Samba will see the username as WINDOWS_CLIENT_HOSTNAME\your_username, conclude that it has no way to verify any users belonging to domain named WINDOWS_CLIENT_HOSTNAME, and will reject the login. To successfully log in to a stand-alone Samba server from a stand-alone Windows client, you may have to specify your username as SAMBA_SERVER_HOSTNAME\your_username. If you are logged in with a local account (or your client system is not joined to an AD domain), Windows may automatically prefix the username with the client hostname unless you specify another domain name. you will be authenticating as AD_DOMAIN\your_username, not just your_username. When your Windows client system is joined to an Active Directory domain and you're logged in with an AD account, it automatically prefixes all unqualified usernames with the name of the AD domain of the user, i.e. There's one more thing you may have to do client-side. This advice is obsolete: those registry hacks may no longer work in current versions of Windows, and allow anyone who can monitor your network traffic to trivially capture your password.) (Very, very old instructions from the previous millennium may recommend disabling password encryption in Samba, and using certain registry hacks to allow Windows to emit unencrypted passwords to the network. It can only be compared to another password hash that uses the same algorithm. When a client sends a SMB authentication packet, it includes a hashed password. This step is necessary because the standard system passwords in /etc/shadow are hashed in algorithms that are incompatible with the password hash algorithms used in the SMB protocol. Then you'll need to use the smbpasswd command to set up a password to authenticate my_linux_username for Samba: sudo smbpasswd -a my_linux_username In the share settings in smb.conf, you'll need to specify the names of users and/or groups that are allowed to write to the share, using a write list =.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |