search for: blackpenguin

Hi, I setup a secondary DC to server as a fileserver for testing purposes. The DC (DCBACKUP) in question runs on top of a Fedora 21 x64 with VirtualBox. The DC OS also runs Fedora 21 x64. The smb.conf follows: [global] workgroup = BPDNET realm = ad.blackpenguin.org netbios name = DCBACKUP server role = active directory domain controller vfs objects = acl_xattr map acl inherit = Yes store dos attributes = Yes [netlogon] path = /usr/local/samba/var/locks/sysvol/ad.blackpenguin.org/scripts read only = No [sysvol] path = /usr/local/samba/var/locks/sys...

...gt; Hi, > > I setup a secondary DC to server as a fileserver for testing purposes. The > DC (DCBACKUP) in question runs on top of a Fedora 21 x64 with VirtualBox. > The DC OS also runs Fedora 21 x64. > > The smb.conf follows: > [global] > workgroup = BPDNET > realm = ad.blackpenguin.org > netbios name = DCBACKUP > server role = active directory domain controller > vfs objects = acl_xattr > map acl inherit = Yes > store dos attributes = Yes > [netlogon] > path = /usr/local/samba/var/locks/sysvol/ad.blackpenguin.org/scripts > read only = No > [s...

...gt; Hi, > > I setup a secondary DC to server as a fileserver for testing purposes. The > DC (DCBACKUP) in question runs on top of a Fedora 21 x64 with VirtualBox. > The DC OS also runs Fedora 21 x64. > > The smb.conf follows: > [global] > workgroup = BPDNET > realm = ad.blackpenguin.org > netbios name = DCBACKUP > server role = active directory domain controller > vfs objects = acl_xattr > map acl inherit = Yes > store dos attributes = Yes > [netlogon] > path = /usr/local/samba/var/locks/sysvol/ad.blackpenguin.org/scripts > read only = No > [s...

...Secondary DC as fileserver within VirtualBox Hi, I setup a secondary DC to server as a fileserver for testing purposes. The DC (DCBACKUP) in question runs on top of a Fedora 21 x64 with VirtualBox. The DC OS also runs Fedora 21 x64. The smb.conf follows: [global] workgroup = BPDNET realm = ad.blackpenguin.org netbios name = DCBACKUP server role = active directory domain controller vfs objects = acl_xattr map acl inherit = Yes store dos attributes = Yes [netlogon] path = /usr/local/samba/var/locks/sysvol/ad.blackpenguin.org/scripts read only = No [sysvol] path = /usr/local/samba/var/locks/sys...

I am using samba 4.1.0 on Fedora 19 x64. I compiled from source and provisioned from scratch. I joined the domain with a Windows 7 Pro x64 machine. I do see the shares on the server, but I do not have the security tab to set permissions on the folders. The unix filesystem rights are set to root:root to 770. I do not know what the problem is. I did not experience this issue on previous versions on

I am using samba 4.1.0 on Fedora 19 x64. I compiled from source and provisioned from scratch. I joined the domain with a Windows 7 Pro x64 machine. I do see the shares on the server, but I do not have the security tab to set permissions on the folders. The unix filesystem rights are set to root:root to 770. I do not know what the problem is. I did not experience this issue on previous versions on

Hi all, I have been experiecing this issue since the first release of samba 4.0. I am running samba 4.1.7 in a production environment for about 25 people - higher the user/work volume, the more frequent the security access loss. Every once in a while a user calls me to report that he cannot write/delete or modify certain files or folders. The only fix that I can apply (this also worked in samba

Hi all, I've been running Samba 4.1.6 in production for 2 weeks now and it's been great. However I noticed a huge security flaw today that I hit only once. I access Samba4 shares over the VPN that is irrelevant since the security access is user-based, not IP based. What happens right after the connection, Windows tries to read the shares and some are empty, but they are not supposed to