I have tried in vain to sort this myself but have now got into a BIG mess (why does it have to be so **** hard ?).
On my machine I have the following partition setup
File System: NTFS
Mount Point: /tmp/Folly_Data
Mount By: Volume Label
Label: Folly_Data
UUID: 26E71D7E25588
This is mounted, I have configured smb.conf with the following
[global]
workgroup = Folly.Office
netbios name = Folly_Data
server string = “”
local master = yes
os level = 65
passdb backend = tdbsam
printing = cups
printcap name = cups
printcap cache time = 750
cups options = raw
map to guest = Bad User
usershare allow guests = No
ldap admin dn =
wins server =
wins support = No
[Folly_Data]
available = Yes
browseable = Yes
inherit acls = No
path = /tmp/Folly_Data
read only = No
guest ok = Yes
and restarted smb.service/nmb.service
I can see the share from my Windows machine but have no permission to write to it (Permission Denied), I have tried
NTFS is a non-Linux file system type. It has no ownership, nor permission bits. To make it (more or less) usable inside Linux, user/owner and permission bits are faked. These fakes are decided at mount. I am not sure how you mount this one, when it is using an /etc/fsatb entry, then better post it. In
man mount
you can find how to use mount options to set another users:group then the default and same for permissions.
But why do you use an NTFS file system? As I see it you are not using it for direct access by a MS Windows system (in multi-boot).
I do not know much about Samba (no MS systems in the house), but I think with a Samba server you can share data from a Linux system and data on a Linux system is normally stored on a Linux file system.
==========
I see you are rather new here. Welcome and the following message:
There is an important, but not easy to find feature on the forums.
Please in the future use CODE tags around copied/pasted computer text in a post. It is the # button in the tool bar of the post editor. When applicable copy/paste complete, that is including the prompt, the command, the output and the next prompt.
Seeing the other thread I guess the OP mises some basic understanding about the one directory tree of Unix/Linux, how to build it with mounting file systems (and what is mounting) on one side and what is exactly exporting (to other Unix/linux systems) or sharing (to non-Linux systems) of parts of that directory tree.
It may also be that he did not adhere enough to the rule: When going to Linux, forget everything you learned about Windows.
I have some written some basic material about this, but it is all in Dutch and i assume there is enough about this in English to be found.
You need to map the user on the Windows machine to a suitable user on the Linux machine – possibly the one who owns the Samba Share or, a user who is a member of the Samba Share user group – with “write” permissions on the shared directory.
While this is true, there is additional consideration needed when sharing an NTFS filesystem via samba as Henk already mentioned. This is really the cause of the issue the OP has run into. Various mount options (including umask, fmask, dmask), can be employed to essentially emulate the ownership as required. Some info on this…
Please, please, please, never, ever, consider setting up a Samba Share where the owner of the exported directory which shall be writeable by the clients on the network, is the Linux (or UNIX®) user “root” – you’ll have to map the users on the clients to the Linux (system) user “root” – which is something that Samba doesn’t allow anyway …
My personal preference is, to create sub-directories below the Linux system’s top level directories – which are usually owned by “root
” …*=2]The owners of the sub-directories, which are exported either as Samba Shares or NFS exports, are non-system (UID > 499 – GID > 999) pseudo-users – no login (the login shell is ‘/usr/sbin/nologin’), the home directory is the directory to be exported and, the password is locked and doesn’t exist …
The (writeable by the network clients) user directories included either in the Samba Share or, the NFS export, are owned by the Linux users who wish have their directories written by network clients …
It comes down to the UNIX® and Linux system philosophy that, the entire system shall not be visible to the network.
The Redmond folks needed quite some time before, they also realised that, the idea is a sensible one … >:)
If you care to re-read the GOKIWI’s opening post, you’ll see that was not their intention. However the chmod and chown commands failed because NTFS does not support *nix permissions. They need to be emulated (or faked if you will) as already described. Best not to use that file system for sharing in a samba context.
Like @deano_ferrari already explained, the problem reported is due to using a non-Linux file system on Linux.
I see no use for a non-Linux file sytem here at all, the more because the OP has not explained why he uses an NTFS file system.
Until now this is not a Samba question/problem at all. As soon as it becomes one, I will quit from the thread due to lack of my knowledge about the finery of Samba serving.
I suspect that, Samba isn’t using “NTFS-3G” – that’s a method using FUSE to allow Linux users to mount a local NTFS partition with read and write support …
Please be aware that, Samba is designed to share native Linux File Systems to Redmond (Windows) clients – where the Redmond box treats the remote File System as being a Microsoft File System even though, physically, in reality, it ain’t …
No, samba is not aware of the underlying file system. However, how the NTFS file system is mounted ultimately impacts the effective permissions, and thus samba in this case.
