I have a virtual machine in ESX with snapshot; unfortunately when trying to commit the snapshots, vmware somehow lost track of the whole structure; the virtual machine got one week back, while on the disk there are still the files with the snapshot data (esx completely lost track of these files). Is there a way to force commit of these snapshot files into the virtual machine?
ondra's questions
I am going to migrate data from one disk array to another. The hosts connected to the storage are Windows 2003/2008 servers. Is there a way to migrate the data in such a way that the OS would retain e.g. all share configuration?
How can I do that? I tried to copy one disk to the other on Linux but that still seems to change the drive letter and remove the share configuration.
Alternatively, is there a way to dump the share configuration and restore it back?
Is there a way to find amount how much memory is mlocked on HP-UX? Either on process-specific or system-wide basis?
I have a samba server that authenticates users using LDAP, however it does have kerberos enabled as well. Unfortunately users authenticated using kerberos cannot delete files. I can test this using smbclient - if I use the '-k' switch, I cannot delete the files, if I don't, I can. The users does have read/write/execute access to the directory from where he is trying to delete the file.
Any idea what might be wrong?
The smb.conf:
security = user
passdb backend = ldapsam:ldap://ldap1.[...]
ldap ssl = start tls
ldap suffix = dc=mff,dc=cuni,dc=cz
ldap user suffix = ou=accounts
ldap group suffix = ou=groups
ldap admin dn = uid=[...]
ldapsam:trusted = yes
kerberos method = system keytab
realm = [...]
use spnego = yes
unix extensions = no
winbind enum users = Yes
winbind enum groups = Yes
winbind cache time = 7200
idmap cache time = 7200
idmap uid = 8000-50000
idmap gid = 8000-50000
name cache timeout = 7200
delete readonly = yes
[share]
comment = "Uzivatelska data"
path = /export/home
public = no
writable = yes
hide unreadable = yes
I have installed the samba server (3.4.0, Ubuntu) with ldapsam environment and suddenly a logged user is automatically added to grups 10002, 10003 and 10005. This is bad as incidentally these gid's are used by other users (by default we have uid=gid) and so these users can see in wrong directories etc.
samba 3.0.33 didn't do this.
After a whole lot of debugging I found out that this corresponds to:
sid S-1-1-0 -> gid 10002
sid S-1-5-2 -> gid 10003
These probably correspond to: "Everyone" and "Network rids" (???)
And I cannot find the SID value for 10005, could probably find it with gdb...
Is there a way to at least remap these values to something harmless? The best way would be to not let the user have these groups at all.
I have configured vsftpd with the "text_userdb_names=YES" option, which is expected to put user and group names into the listing. The server is configured with nscd and ldap. The users are chrooted into a 'general root' directory, but that doesn't affect the result (not chrooting still fails).
The problem: obvious timeouts and unsuccessful resolving of 'group names'. The 'ls' output contains correct usernames but instead of a groupname there is a number.
There are 2 possibilites to modify cache settings in the Adaptec Storage Manager. - Physical drive - Write-back or Write-through - Logical drive - Write-back, Write-back only with battery, write-through
I do have a battery, so I would set Write-back only with battery for logical drive. However, what should I set on the physical drive?
Is the write-back caching on physical drive provided by the controller backed by the battery as well - or is it provided by the drive and it should be switched to write-through? (I do not have a UPS yet). I have not found any clue in Adaptec documentation, the ASM Guide even does not mention the logical drive settings.
The adaptec model is 52445, but the settings seems to be quite generic in the Adaptec Storage Manager.