This is a problem that I (sorta) fixed already, after about 14 hours of struggle, but I’m curious as to why I had to fix it the way I did.
The situation was this: I have two Manjaro Linux computers, A and B, each sharing 3 dirs, with the 3 dirs on A mirroring the 3 dirs on B (to be kept in-sync using FreeFileSync, as a form of “poor man’s RAID”).
The problem I had was this: The 3 dirs on A were subdirs of “/home/aragorn”, but the 3 dirs on B were subdirs of “/loc” (for “local”). Computer B could see the shares on computer A, but computer A could not see the shares on computer B. All the permissions were set correctly, and yet, the dirs on B looked empty to A.
The solution I found (by process of elimination) was this: Move the shares on computer A from “/loc” to “/home/aragorn”. Suddenly all of my computers can see the shares on all the others.
So, why can Samba share from, say, “/home/jack/myshare/”, but not from, say, “/local/myshare”? Is there some unwritten rule “Can’t share from anywhere but subdirs of user’s home directory” or something?
Interesting. I was wondering about that, as all the evidence seemed to indicate otherwise.
Well, that was my first inclination, but I made sure that everything being shared was owned by “aragorn:aragorn” with permissions “drwxrwx—” (user & group get full control, and to everyone else it’s invisible). I also matched that in the “/etc/samba/smb.conf” and “/etc/fstab” on both computers.
And yet, Computer A could not see the shares on B which were subdirs of “/loc”. Whereas, when I moved those subdirs from “/loc” to “/home/aragorn”, with all the same permissions (in dirs, files, smb.conf, and fstab), everything worked fine.
Which is why I was wondering if Samba has a systemic problem with sharing folders such as “/local/drive7”, whereas it has no problem sharing “/home/myname/local/drive7”. You say no, but unless I’m missing something, the evidence seems to say yes.
And I tried all these shares two ways:
As cifs shares in “/etc/fstab” (with uid=1000, gid=1000, and samba username and pw written directly into fstab). The troubled shares mounted with no error, but the shared dirs showed as empty, both in Dolphin and in Konsole “ls”.
By double-clicking folder icons in Dolphin. That brought up a pw box, but the box rejected my samba username & pw and just kept looping. closing the box yield empty folders.
Moving the shares to “/home/aragorn” fixed all that, but I’m inclined, as you are, to think “that shouldn’t be necessary”. Hence my puzzlement.
[Addendum, a few minutes later:] OK, I just ran a simple experiment. Instead of trying to share multiple dirs with terrabytes of data, I went into “/” in Konsole as “aragorn” and did “sudo mkdir loc”, changed owner to “aragorn:aragorn” and perms to “0770”. went into loc, “mkdir Perlman”, when into Perlman, and made file “Itzhak.txt” with content “Itzhak Perlman is my favorite violinist.”. I also added the appropriate section to “/etc/samba/smb.conf”. Then i went to the other computer and typed “smb://excalibur/perlman”, and voila, the file “Itzhak” immediately popped up, and I can rename it, read it, and edit it via Samba.
SO, yes, you’re right, Samba has no problem sharing from random subdirs of “/”. Which leaves me more puzzled than ever as to what was going wrong before. HUH. Color me puzzled. :::scratches head:::
[Addendum 2, later:] Wait a sec, there’s one HUGE difference between what I was doing before, and this simple test: Before, I was first mounting devices (one partition of an internal SSD, and two partitions of an internal HD) to subdirs of “/loc”, and trying to share those with Samba.
But in my simple test, “/loc/Perlman/Itzhak.txt” is a file directly on my main Linux “/” device (a 500GB M2 SSD plugged directly into pcie).
So maybe Samba was having an issue sharing directories with external partitions mounted to them? But if so, why would mounting those external devices to subdirs of “/home/aragorn” suddenly make them “shareable”?
Yes. That was the very first thing I made sure of: that all users and ownerships and permissions are correct in all places (“/loc”, all subdirs of “/loc”, recursively for all contents of all subdirs of “/loc”, Linux users on both machines, Samba users on both machines, relevant sections of “/etc/samba/smb.conf” on both machines, relevant source-mount lines in “/etc/fstab” in both machines, relevant network-mount (cifs) lines in “/etc/fstab” in both machines). All double-checked, triple-checked, quadruple-checked, quintuple-checked, over two 7-hour sessions a few days ago. So that ain’t it.
And yet, neither machine can see any shared mounted devices in the other machine that were not mounted to subdirs of “/home/aragorn” (eg, if I mount those devices to subdirs of “/loc”, it won’t work).
So, I’m beginning to think it’s a matter of Samba doesn’t like to share devices mounted outside of “/home”.
As I found out by experimentation, Samba doesn’t mind sharing directories outside of “/home”, as long as they don’t have devices mounted to them. I put a file called “Itzhak.txt” in “/loc/Perlman” and shared that dir, and the other computer instantly granted full access to that file.
But when I mounted a partition of my SSD to “/loc/Imladris”, the other computer says “access denied”. But when I mount the same partition to “/home/aragorn/Imladris”, it works fine.
Maybe it’s some weird interplay between the fstab line the mounts the partition, the smb.conf lines that share it, and the fstab line on the other computer that mounts it as a cifs share.
Or, maybe Samba just has an unwritten rule “can’t share devices mounted outside of sharer’s home directory”.
On the computer that had the shares in “/loc” which the other machine couldn’t read, the three devices being shared were:
Bootable Windows partition on internal SATA SSD.
Data partition on internal hard disk.
Data partition on internal hard disk.
As far as I can see, the permissions are set correctly. And indeed, those fstab lines work fine as long as I mount those 3 devices to subdirs of “/home/aragorn”. But if I mount them anywhere else, they do not “work fine”, which is the whole point of this thread.
For reference, the 3 fstab lines that mount the 3 devices are:
#-----------------------------------------------------------------------------------------------------------------------
# Local file systems:
# Note: Use UUID for these, because that identifies the file system, not the partition.
# Note: These are non-Linux file systems, so we can use uid, gid, and umask to set "effective" permissions.
# Device = "Samsung SSD Main Internal Boot Drive", Serial = S62ANZ0R812114K, dev-path = "/dev/sda":
UUID=A4E426A9E4267DA4 /loc/Imladris ntfs defaults,auto,nofail,uid=1000,gid=1000,umask=0007,x-gvfs-show,x-gvfs-name=Imladris 0 2
# Device = "Main Internal Data Hard Disk", Serial = Z4YADTT8, dev-path = "/dev/sdb":
UUID=A0E42A6AE42A4340 /loc/Lothlorien ntfs defaults,auto,nofail,uid=1000,gid=1000,umask=0007,x-gvfs-show,x-gvfs-name=Lothlorian 0 2
UUID=08DF0C4F08DF0C4F /loc/Gondor ntfs defaults,auto,nofail,uid=1000,gid=1000,umask=0007,x-gvfs-show,x-gvfs-name=Gondor 0 2
And that doesn’t work. But if I change all 3 instances of “/loc” to “/home/aragorn” (and make the corresponding changes in “/etc/samba/smb.conf”, then it does work.
I wonder if the fact that the 3 balky partitions are NTFS (to facilitate dual-booting on my older computer) rather than EXT4 is related? That does muddy the permissions a bit, because Linux has to use “effective” permissions applied via “uid=1000,gid=1000,umask=0007” in fstab, whereas EXT4 partitions have their own built-in permissions for each individual file.
Hmmm. Well, I could try setting “umask=0000”… Nope, doesn’t work, setting it back to 0007.
Trying mounting file system in “/home/Imladris”… That works! I’m surprised, because that’s a very unorthodox way to use “/home”, as its subdirs are supposed to correspond to users, not mountpoints.
Trying “/mnt/loc”… Nope, doesn’t work.
So, it seems that Samba can’t share NTFS file systems (and maybe can’t share any file systems) mounted to random subdirs of “/”; it can only share them if mounted to subdirs of “/home”. (Yes, it can share directories and files from, say, “/random/path”, but not mounted files systems.) And permissions appear to have nothing to do with it. Unless I’m missing something, this appears to be the case.
Samba is, as Andrew Tridgell likes to point out, is bug for bug compatible with Microsoft SMB/CIFS.
Unfortunately, because I don’t use MS Windows, I am unable to comment on how permissions work or don’t with NTFS Partitions.
That might be true, that does not mean the others person necessarily understands what you mean.
Yes I read yours, I have a copy of both your smb.conf files, so I could run a diff on them.
if it works in /home/aragorn but not in /mnt/loc or where ever, then it is a permissions issue.
the user aragorn has all the required permissions, to that directory.
It’s just a directory, regardless of how it was created, there is no rule that says you can’t do what you did. So there’s nothing unusual there, provided aragorn has permissions to read and write to that directory.
What are the permissions you’ve set on /mnt/loc
who is the owner, the group, and does aragorn belong to the same group?
Permissions on the content is irrelevant when it comes to NTFS - what is relevant though is your mountpoint - which must have the the correct permissions set e.g.
chmod ugo+rw /loc
Sharing partitions is not an issue - when they have been mounted no matter where they are mounted - my personal preference is either /a on a workstation and /data on a server with additional bind mount into /srv for system protection.
I have been a sysadmin for a living and when creating shared resources always use a dedicated structure - there is nothing that beats predicatability when it comes to troubleshooting.
One of your partitions
It would be better to use a more permanent idenfication and label the partition, also remove the fluff added by Gnome Disks or your troubleshooting steps
When dealing with NTFS - the permissions on the mountpoint e.g. /loc will dictate what the samba service will allow.
Your mystery - moving the mountpoints inside your home is permission related - my guess is that you didn’t create a samba user.
Perhaps the combination of a missing samba user, your gid, uid in the mount options and the mount inside a tree with initial permissions of your gid and uid inadvertently solved your issue.
I think you have been labyrinting a xy problem where you would likely be better of starting from scratch.
I am the trial’n’error guy - so I have often forced myself to start over - attacking the issue from a different angle. This forum has been an invaluable tutor in that regard.
NTFS doesn’t use “file permissions”, but rather, “access control lists”. Which forces Linux’s mounter for such FSs – I seem to recall it’s called “FUSE”, meaning “Filesystem in USErspace” – to generate fake “permissions” on-the-fly at mount time. That’s why I use “uid”, “gid”, and “umask” when mounting local NTFS drives in fstab: it tells Linux to pretend that these files have those attributes and treat them accordingly.
I also do the same with fstab mount type “cifs” (network shares), though I should probably not, as the other end has already done that. I’ll have to experiment with just leaving those out; I imagine the CIFS mounter should then just mirror whatever the FUSE mounter on the other end has done (assuming NTFS, which most of these partitions are, because they’re left-over from my Windows days).
I’m in the process of slowly converting everything over from HDs to SSDs, from USB-3 to USB-C, from MBR to GPT, and from NTFS to EXT4. But it takes time and money. Probably by Jan 1 2024 I’ll have most data on SSD/GPT/EXT4. Then a typical line in fstab can be as simple as:
Whereas to get an NTFS device to work the way I want, I have to also add “,uid=1000,gid=1000,umask=0077”.
That does not appear to be true, at least in regards to mounting local NTFS devices. FUSE just resets the permission of the mount directory to whatever one specifies in fstab, which will also be applied to the mounted files and directories.
e2label doesn’t work on NTFS, and that partition is already labeled “Lothlorien” anyway, and it’s label is irrelevant because I’m mounting by UUID.
That results in NTFS partitions always being mounted as root:root, which won’t work because my main user can’t access them:
No. That’s the first thing I did when I began this saga, 20 hours (of struggling with this particular problem) ago (though several months, now, in real time).
Those were all checked many times over in both the “/etc/fstab” and “/etc/samba/smb.conf” files on all computers involved, and in regards to the various mount-point directories involved, during the 20 hours I was fighting with this problem. So, no, that ain’t it.
Interesting; I’d never heard of that. But that is not the issue here. There is no “y”, just “x”. And “x” is:
Question: “How can I use a Samba client to mount network shares of a directories not in ‘/home’ in which have been mounted NTFS partitions?”
And the answer appears to be: “You can’t, so stop trying. Mount the NTFS partitions to be network-shared to sub-directories of ‘/home/’ and everything will work fine. Don’t, and it won’t. Owners, users, Samba users, and permission are mostly irrelevant; location is everything.”
And I did that, and everything works. I don’t have another 20 hours to waste on it; the first 20 was enough. If I’m going to be spending 40-hour work weeks working on Samba, I’d have to insist on a salary from them.
So I have to face reality: Samba is a home-sharer, not a network server. As long as I don’t try to make it something it’s not, it works fine.
Maybe in coming months I’ll find time to do more experimenting. But probably not. I rather like the idea of having all mount points inside “/home/aragorn” anyway, as I have Dolphin set to open to ~ on launch, which speeds-up navigation to locations such as “~/rem/Removable-Device-13” or “~/net/Network-Share-7”
So I’m going to mark this message as “solution”. Bottom line: “Samba can’t do that, so do something else instead.”
Not so much a “solution” as a “realization”. Question: “How can I do X?” Eventual realization: “I can’t, so I should stop trying and do A, B, or C instead”. I see soooo many people in this world failing to do that; results are usually not good (heads beaten needlessly against walls, dead horses beaten to pulps). My motto is “if at first you don’t succeed, try 1 or 2 more times then give up and do something else; life is short”.
Yep, the NTFS file system works with Linux as seamlessly as trying to plop a Honda Accord engine in a Red Bull F1 car and expecting it to be competitive. I’m slowly phasing it out. As I replace my old external hard disks, I’m going from HD to SSD, from MBR to GPT, from NTFS to EXT4, and in some cases from unencrpyted to LUKS.
But in the mean time, I’ve at least learned this realization:
“If intending to Samba-share a mounted NTFS partition, mount it to a sub-directory of ‘/home/my-user-name’; if you do that, it will work; if you don’t, it won’t”. I’m not sure why that is true, or if that’s supposed to be true, but I’ve found that it’s so.
You are still focused on how you think it should be done - instead of configuring it as it should be done.
I am sorry to tell you - you are mistaken - Linux is not Windows.
It all boils down to permissions and if you don’t understand permissions or ACL (access control list) and the defaults then you get confused.
You can setup samba to share NTFS formatted device mounted on /data or /srv/samba but if you fail to set the correct permissions on the mountpoint you won’t be able to write only read.
NTFS is treated on Linux as vfat, exfat, fat32, fat16 - that means there is no permission restrictions on the filesystem.
Permissions on the mountpoint however will determine who can do what.
u=user or owner
g=group
o=other
The defaults is controlled by the umask binary - which is called in /etc/profile and defaults to 022 which translates to 755 which translates to u+rwx,g+rx,o+rx
If you mount the NTFS device in a folder which has only read permissions - then you cannot write to the device.
When you create a folder in the root of the filesystem e.g. /loc - which you can only do as root - the permissions is user (root) rwx and go r-xr-x.
drwxr-xr-x 2 root root 4096 Jan 28 11:19 loc
When you create a folder inside your home it is the same user (you) rwx and go r-xr-x which is why you can write to a mountpoint in your home but not in root.
drwxr-xr-x 2 nix nix 4096 Jan 28 11:20 loc
So to be able to write to a folder like /loc used as mountpoint for your NTFS volume you need to explicitly set write permissions either world write or by using a group permission.
Let’s imagine you don’t care which users write to /loc you would set permissions on the folder to
Interesting post. However, every single statement (except one) in your post is false. (I double-checked.)
Most of the items you mention, I already checked, many, many times over, in my marathon 20-hour networking session some months ago. Do you really think I would have missed any of those items, much less all of them?
But I’ve got waaaaaaaay too much time on my hands right now, so I’ll reply to your points one by one.
No. No X or Y, just a simple question (“How can I do X?”) and a simple answer (“You can’t.”).
No, no, and no. That’s wrong all three ways.
Firstly, that’s not what “XY” (as you’ve defined it) even means! It refers to a user’s quest for a generic solution to a high-abstraction-level problem (which may not be possible) in conflict with a forum moderators desire to narrow the issue down to a single, very-specific, low-abstraction-level issue which actually can be solved (but which totally ignores the bigger picture). As soon as one stops thinking in terms of the “XY” paradigm, the better; reality is messy, yes; but any attempt to clean it up just makes the problem worse, not better.
Secondly, I’ve already made it abundantly clear that I’m not addicted to any particular way of doing things, and indeed, after spending a few days trying to do things a certain way, I gave it up as “not working” and did things a different way (which does work).
Thirdly, I already tried all of your recommendations months ago, and they all failed.
Sorry, but the following two things are not equivalent in all cases:
What the documentation says should happen.
What actually happens.
Computer science is replete with violations. I’ve seen those two things diverge so spectacularly you’d find it hard to believe. (Eg, a C program which was supposed to print the number of partitions of an integer, but instead printed a chapter of JRR Tolkien’s “The Lord Of The Rings”. The textbooks say that can’t happen. But it did. Computers care not about human conceits and only obey their instruction sets.)
No, and no.
Firstly, you’re clearly enjoying this (for some reason I can’t fathom), so no, you’re not sorry.
Secondly, I never says “Linux is Windows”. This is the second or third time you’ve engaged in that particular misquote. I have no idea where you’re getting that.
In this case, no, it does not. For whatever reason, Samba does not treat “/home” and “/random_dir” equivalently. You can change permissions until pigs fly, trying every possible value from octal 000 through octal 777 and it won’t change that fact. I don’t know if that’s supposed to be true or not; but it is.
No, no, no, and no.
Firstly, no, I do not “not understand permisisons”.
Secondly, no, I do not “not understand ACLs”.
Thirdly, no, ACLs are not permissions (or anything remotely close). NTFS and EXT4 have very different ways of trying to do security, and they don’t map well to each other. (Which is why I’m in the process of slowly converting all of my storage partitions from MBR+NTFS to GPT+EXT4.)
Fourthly, I went way beyond the defaults, so “defaults” have nothing to do with it.
You can setup samba to share an external NTFS partition mounted to “/random_dir”, yes. And you can change ownerships and permissions until pigs fly, yes. But external computers won’t be able to read it, no matter what ownerships or permissions you set the mountpoint to. (They’ll hang when trying to process username and password.) I verified that many times over.
But when you move “random_dir” to inside “/home/my_user_name”, suddenly everything works. You can purposely set wrong permissions, and it still works. You can purposely set wrong owner, and yet it still works. (To see why, do “ls -al” on the mountpoints before and after mounting; Samba changes the permissions, so whatever you set matters little.)
No, NTFS is treated as “ntfs”. It has some similarities to “vfat”, yes; but fuse won’t mount it correctly if you get the line wrong in “/etc/fstab”.
Exactly! This is the one true thing you say in this entire post. ACLs are not permissions and permissions are not ACLs. They’re so unrelated that Linux doesn’t even try to map them to each other. Instead, permissions are established in other ways altogether. And mostly not by what the permssions are set to on either mountpoint (the send mountpoint or the receive mountpoint), but rather, by what’s in “/etc/fstab” and “/etc/samba/smb.conf”, and by what’s in the Samba source code.
Mostly not. “/etc/fstab” and “/etc/samba/smb.conf” appear to override that.
Unfortunately, no. To start with, “/etc/profile” is never sourced on my system. And even when it is manually sourced (“source /etc/profile”), it applies only to a shell in a console, and whatever it does is reset if the console is closed and re-opened.
The same applies with “umask”: it appears to apply to a shell in a console, and when the console is closed and re-opened, it reverts.
So I don’t know where Manjaro Linux stores its infuriating “022” default umask, but it’s not “/etc/profile”, wherever it is.
I wish I could know where that’s stored; I’d like to change it to “002”. (I changed it to “002” in “/etc/profile” but that does nothing; it’s still 022. I even put it in file “/usr/bin/startup.sh” with permissions set to 777, and set that to run on system startup, but it does nothing.)
I’m not so sure about that! Have you tried? I think you’ll find that that’s controlled by “/etc/fstab” and “/etc/samba/smb.conf”, not by send-mountpoint or receive-mountpoint directory permisisons.
However, that’s not the source of the problem anyway, because both mountpoint directories were set to “aragorn:aragorn” (not root:root), and 775 (not 755 or 555 or whatever).
True, but irrelevant, as anyone but a complete Linux newb (which I’m not) would immediately do “sudo chown myname:myname /mountdir” and “sudo chmod 775 /mountdir” (which, of course, I did; not that this helped).
That paragraph is hard to parse, but the gist appears to be a basic explanation of what Linux permissions are. But I’ve already know that for decades, so it’s not new, relevant, or helpful information.
Like I keep repeating (in this and many previous posts in this thread), both the send and receive mountpoints were all set to "aragorn:aragorn: and 775, so that’s not the issue, even if Samba pays attention to those (which it doesn’t appear to do anyway).
Anyone on that computer could write to that directory, yes.
With Samba, alas, that’s not guaranteed at all.
If you have an NTFS partition mounted to “/loc” on computer Agamemnon, and you share it with Samba server, and Samba client on computer Alexander tries to mount that share to any directory (let’s say, “/home/fred/net/agamemnon”) – or, just open it in Dolphin – either way I think you’re going to have major problems. I think your Dolphin will freeze up and not connect, and your cifs mounter on Alexander will likewise be unable to mount the network share. Try it and see. If it works on your computer, yay. It certainly won’t work on mine. No, not even after trying all the things you recommend. I already tried all of those months ago, and none of them are even remotely close to being the problem.
Again, the central truth is that Samba is a home sharer, not a file server. No amount of contradicting that fact will change it. Share to-and-from subdirs of “/home” and all will be well. Don’t, and it will fail (at least, with NTFS file systems). Mountpoint ownerships and permissions (both for the NTFS-file-system mountpoint on the server computer and for the network-share mountpoint on the client computer) appear to have nothing to do with it. That is the “solution”. You can “unsolution” it all you like, but that won’t change the fact that you’re wrong. The physical reality is that it does not work that way, at least not on my computers. I wish it did work that way, but it doesn’t.
