|
Problem description: XenCenter won't allow allow me to use my samba share as a CIFS Storage Repository. It works when I map it is a network drive, but not with XenCenter. As I am a computer janitor I literally cannot figure this out. Additionally, with network drive mapping, it allows me to map it by name rather than IP; eg \\ISOREPO rather than \\123.23.2.1, which I sense could be / is part of the problem. Is there a way to fix this?I am thinking it may also have something to do with the it only resolving through hostname rather than allowing through IP. Attempted fixes: Changed hostname, restarted, reinstalled Samba Server, used google forever, even went so far as to install a Windows 2012 VM to attempt with that, no dice on that as well. Spent approx four hours googling to find the solution to this problem to no avail. Recent changes: None -- Operating system: CentOS 6.6 x64 System specs: CitrixXen VM (not on the same Xen server that I am attempting to use this CIFS share as a storage repository on, though it doesn't work on the same either). General setup, 1 core, 2 gb RAM, 1 TB thin provisioned disk space. As previously stated it works when mapped in Windows. Location: America I have Googled and read the FAQ: Yes to the point that my eyes are near bleeding Also, below is the smb.conf file: code:du -hast fucked around with this message at 00:06 on Jan 20, 2015 |
#
?
Jan 20, 2015 00:04
|
|
|
|
| # ? Apr 27, 2024 19:32 |
|
|
Hmm.. XenCenter is the management application for XenServers, if I recall correctly. When you tell XenCenter to use a share as a storage repository, it will probably just forward the request to some XenServer: they will be the ones connecting to the share. The fact that your workstation can map the share indicates that the share basically works, but it tells us nothing about whether or not the XenServer(s) can connect to the share. If C is the thing that runs XenCenter (maybe your workstation, or some other VM?), S is the XenServer controlled by the XenCenter and I is the ISOREPO host, we now know that connection C - I works (because you can map the share) and C - S probably works (because you can control the XenServer). But using the share as a CIFS Storage Repository requires the connection S - I, which is unknown. I'm not sure if the XenServer includes the "nmblookup" and/or "smbclient" commands. But if it does, you might want to login to the XenServer command line (either using the system console, or maybe with SSH) and run "nmblookup ISOREPO" and "smbclient -L ISOREPO -u share". du -hast posted:Also, below is the smb.conf file:  The "security = share" option is deprecated as it does not work with SMB2. In modern systems, it basically makes it harder to predict what username the client system will eventually end up using. Even the smb.conf man page says: "Note that it can be very confusing in share-level security as to which UNIX username will eventually be used in granting access." For example, if you are trying to connect as share@XenServer1, the usernames that will actually be tried are: the username, the name of the share, and the name of the client host, and if "user" or "username" parameters are used in the share configuration, any listed usernames are added to this mess. (On the other hand, if "guest only = yes" is set on the share, only the guest username is tried... and that is usually "nobody" unless a different guest username is configured.) Please change this to "security = user" to save yourself some headaches. Since the "encrypt passwords" has its default value, you will need to use the "smbpasswd" command to add the necessary user(s) to the local smbpasswd file and set their SMB passwords. The regular Unix/Linux system password won't be useful here, as the password hashing algorithm used by SMB is not compatible with Unix/Linux password hashes. (This is true regardless of the "security" setting.) Moving on... du -hast posted:
The things under the "Share settings" comment line will actually be default values for any shares defined later. Technically there's nothing wrong with that, but setting a default "path=" is rather useless, and having both "writable = yes" and "guest ok = yes" as defaults for all shares unless overridden per-share is not necessarily wise: if you forget to override those settings as needed when creating a new share, you might create a share where anyone may log in without a password (i.e. as guest) and destroy everything. du -hast posted:
The [Share] line actually begins the share definition. This looks OK, assuming that you're planning to connect as user ISOREPO\share (i.e. user "share" of domain "ISOREPO") to share named \\ISOREPO\Share. Specifying the domain with the username might not be necessary, but if it does not work without one, it might be worth a try. Oh, and you should also make sure the share is writeable by the "share" user at the filesystem level, i.e. "chown share:smbgrp /sharepoint; chmod u+rwx /sharepoint" or something similar.
|
|
#
?
Jan 20, 2015 20:39
|
|