I'm trying to use SMB for Time Machine backups. I'm currently using macOS 10.15.5, Samba 4.11.6-Ubuntu and Ubuntu 20.04 LTS.
This is my conf:
[timemachine]
comment = Time Machine
path = /mnt/HD/Backup/timemachine
browseable = yes
writeable = yes
create mask = 0600
directory mask = 0700
spotlight = yes
vfs objects = catia fruit streams_xattr
fruit:aapl = yes
fruit:time machine = yes
fruit:time machine max size = 750G
I can successfully register the share as time machine disk but when it tries to backup I get this error:
[2020/07/17 05:53:28.442317, 0] ../../source3/modules/vfs_fruit.c:4637(fruit_pwrite_meta_netatalk)
fruit_pwrite_meta_netatalk: ad_pwrite [071FEBFA-ACF7-5694-9FB6-A02D91AE7861.sparsebundle:AFP_AfpInfo] failed
If I mount the share via Finder I can successfully create file and folder.
Do you have any clue?
Thanks
I have a similar issue. Looks like it's a bug in samba, and it's fixed in smb 4.17.5.
Related
Using terraform I'm trying to create vsphere_virtual_machine resource. As part of it, I'm trying to find out how to mount virtual disks to a specific folder on a created virtual machine. For example :
Terraform
disk {
label = "disk0"
size = "100"
}
disk {
label = "disk1"
size = "50"
}
How to mount disk0 to volume path D:\mysql\conf and disk1 to volume path D:\mysql\databases on a windows vm created using terraform vsphere_virtual_machine ? Could someone please share your insights here . Thanks in Advance !!
There's nothing in the vsphere_virtual_machine provider that will handle internal operations like that against the Virtual Machine, and I'm not aware of any other provider which can do that either.
Couple workarounds:
check out the remote-exec provisioner, this will let you run some PowerShell or other CLI commands to perform the task you need.
If you're doing this on a regular basis, check out Packer. It can be used to build out a virtual machine, OS and all. You could establish the disk configuration there, then use Terraform to deploy it.
Lastly, look into configuration management utilities. Ansible, PowerShell DSC, Puppet, Chef, etc. These tools will let you make modifications to the VM after they've been deployed.
TLDR; With vfs objects = catia fruit streams_xattr in my smb.conf, files created on the shares using Macs do not inherit permissions and get extended ACLs.
Background
I'm setting up a NAS with a Samba share for our office, which is a 50/50 macOs/Windows 10 shop. Everyone should have access to the shares using dedicated user accounts.
I wanted to leverage the latest enhancements in Samba 4 when it comes to performance with Macs, and TimeMachine support, so I enabled the modules vfs objects = catia fruit streams_xattr
Problem
Permissions are not inherited, and masks are not respected with these vfs objects set. I've tried a number of combinations of force createand create masks, and also (as in the example below) inherit permissions
Without the vfs objects modules set, permissions are as expected.
My smb.conf (relevant excerpt):
[global]
server string = %h server (Samba, Ubuntu)
server role = standalone server
client signing = disabled
unix password sync = yes
vfs objects = catia fruit streams_xattr
fruit:aapl = yes
map to guest = bad user
spotlight = yes
unix extensions = no
browseable = yes
read only = no
inherit permissions = yes
[OurShare]
path = /storage/OurShare
valid users = #office
OurShare has 2770 permissions:
ls -al /storage/OurShare
drwxrws--- adminuser office 4096 Oct 22 03:56
From a Windows machine, any new directory created in OurShare gets drwxrws---, as expected.
However a directory created from a Mac gets drwxr-xr-x+, so they are not writable by the group and that is the main problem here.
$ getfacl on such a directory tells me
# file: OurShare/testfile
# owner: someuser
# group: office
user::rwx
user:someuser:rwx #effective:r-x
group::rwx #effective:r-x
group:office:rwx #effective:r-x
mask::r-x
other::r-x
If I remove the modules vfs objects = catia fruit streams_xattr from smb.conf, then the permissions of files/folders created from Macs match that of those created from Windows - ie. there is no problem.
But without these modules I loose support for fruit:time machine for Mac backup purposes, and fruit:aapl, an extension which "enhances several deficiencies when connecting from Macs" (man vfs fruit).
This is an Ubuntu 19.04 system, with Samba v4.10.0
My question
How can I retain these Mac optimizations in Samba, while still being able to control permissions of created files and folders from the server side?
Thanks for all advice! This is driving me nuts
Turns out this was (already answered)[https://unix.stackexchange.com/questions/486919/creating-a-directory-in-samba-share-from-osx-client-always-has-acl-maskr-x] in the Unix stackexchange.
Answer:
Setting the global option fruit:nfs_aces = no will prevent macOS clients from modifying the UNIX mode of directories using NFS ACEs. An Access Control Entry is part of the Access Control List (ACL). This option defaults to yes - see the vfs_fruit manpage.
I can confirm that disabling this option results in permission inheritance working as expected with Mac clients, as they already are with Windows clients.
Happy to have figured it out!
Background
I was trying to use netatalk to create Time Capsule using an Raspberry Pi 3, following the tutorial here. Some version info:
netatalk 3.1.12
macOS 10.14.5
Raspberian 4.19.50-v7+
Issues and findings
After reaching the last part of the tutorial, and able to connect over afp://, I realised that the volume is read-only.
I re-read the tutorial and realised that I didn't do the first step, because the drive is already HFS+. My guess is the ignore ownership on this volume is essential for netatalk to work properly.
Result / Symptom list
[✔︎] able to connect over afp://
[✔︎] able to mount the external drive on RPi
[𝝬] mounted drive on RPi is read-only
[𝝬] some of the directory can't be read, neither RPi nor via afp://
i.e. cp result in cp: cannot open 'filename' for reading: Permission denied
[𝝬] unable to mount the external drive on macOS
[𝝬] volume is read-only on macOS over afp://
The configurations used
/etc/fstab
proc /proc proc defaults 0 0
PARTUUID=7e67b292-01 /boot vfat defaults 0 2
PARTUUID=7e67b292-02 / ext4 defaults,noatime 0 1
/dev/sda2 /media/tm hfsplus force,rw,user,auto 0 0
/etc/netatalk/afp.conf
; Netatalk 3.x configuration file
;
[Global]
; Global server settings
; [Homes]
; basedir regex = /xxxx
;[My AFP Volume]
;path = /media/tm
[Timestone]
path = /media/tm
time machine = yes
/etc/nsswitch.conf
passwd: files
group: files
shadow: files
gshadow: files
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 mdns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
/etc/avahi/services/afpd.service
<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">%h</name>
<service>
<type>_afpovertcp._tcp</type>
<port>548</port>
</service>
<service>
<type>_device-info._tcp</type>
<port>0</port>
<txt-record>model=TimeCapsule</txt-record>
</service>
</service-group>
Attempts to fix
macOS mount doesn't work
macOS force mount doesn't work
macOS gui diskutil first aid is unable
macOS cli diskVerify is unable to mount and stopped
macOS cli diskRepair is unable to mount and stopped
RPi fsck does not seems to fix the problem
RPi fsck.hfsplus does not seems to fix the problem
Questions and directions
The drive is able to be mounted read-only with some barred access on RPi, the data is likely to be safe. Currently, the drive refuses to mount on macOS, so I can't use macOS to enable the ignore ownership on this volume.
How come the volume (HFS+, created and used on macOS) is mountable on RPi after the tutorial and became unmountable on macOS afterwards?
Give the symptoms, is there any key step that cause this (besides not check ignore ownership on this volume)?
Are there some tracks as a resolution? to either:
mount the drive on macOS, which allow me to fix the permission and backup the data
fix the permission on RPi, so the backup and be done via afp://
or, any better suggestions to overcome these obstacles.
This was driving me up the wall for a week. I take it you are trying to do this from the howtogeek or techradar article?
After the installation, from the raspberrypi I shutdown the system:
sudo shutdown -h now
I unplugged my pi then restarted it (plugged it back in) and ran the following commands:
sudo service avahi-daemon start
sudo service netatalk start
sudo systemctl enable avahi-daemon
sudo systemctl enable netatalk
It worked and I am up and running with my Time Machine!! Hope this helps!
My Setup
3 nodes running ceph + cephfs
2 of these nodes running CTDB & Samba
1 client (not one of the 3 servers)
It is a Lab setup, so only one nic per server=node, one subnet as well as all Ceph components plus Samba on the same servers. I'm aware, that this is not the way to go.
The problem
I want to host a clustered Samba file share on top of Ceph with ctdb. I followed the CTDB documentation (https://wiki.samba.org/index.php/CTDB_and_Clustered_Samba#Configuring_Clusters_with_CTDB) and parts of this: https://wiki.samba.org/index.php/Samba_CTDB_GPFS_Cluster_HowTo.
The cluster is running and a share is reachable, readable and writeable on both nodes, my smb.conf looks as follows:
[global]
netbios name = CEPHFS
workgroup = SIMPLE
clustering = yes
idmap config * : backend = autorid
idmap config * : range = 1000000-1999999
log file = /var/log/samba/smb.log
# Set files creation permissions
create mask = 664
force create mode = 664
# Set directory creation mask
directory mask = 2775
force directory mode = 2775
[public]
comment = public share
path = /mnt/mycephfs/testshare
public = yes
writeable = yes
only guest = yes
ea support = yes
CTDB manages Samba and reports both nodes as OK.
But when i read or write to one of the nodes via the public IP and let it fail (restarting ctdb), the read or write fails. A second write attempt succeeds (the public IP gets taken by the other host successfully).
But CTDB should be able to do this according to https://ctdb.samba.org/ -> IP Takeover?
I have a tcpdump of the new server (the one taking over the public ip) sending a tcp RST to my client after the client sending retransmissions to the server.
Any idea, what the problem could be?
PS: I'm more than happy to provide you with more Information (ctdb config file, firewall configuration, pcap, whatever ;) ) but this is long enough ....
we have two AIX servers, Live and Test. On our live server, I am able to add an entry into smb.conf to allow a directory to be shared across a Windows network as shown in the extract below, displaying the ImportExport shared folder in Explorer:
[ImportExport]
comment = Import Export directory
path = /path/folder
browseable = Yes
hosts allow = <IP>
guest ok = Yes
force user = <user>
forcegroup = pro4
read only = No
create mask = 0777
directory mask = 0777
dead time = 10
However, adding a very similar configuration on our Test server, I cannot even get to the server from a Windows box, I get the "\ is not accessible..." message as if the server does not exist, or there are no shares.
Is there anything else I need to do to the local AIX folder to get this visible to Windows, or can you give me some ideas of what the pre-reqs are for this?
Sorry, I am not an AIX specialist, primarily a Windows house.
Thanks
Got this working now - Samba 3.2.0 was restricted to 14 chars or less for the share name. Reduced, restarted SAMBA and now OK. Thanks all