0

I am compelled to add a new thread as a million people have some other variant of my problem but I cannot seem to find help in their threads. I have tried a dozen things and more, but nothing works.

My setup: Converted a very old T43 Thinkpad to a home server by installing Ubuntu 16.04 (it seemed to be the only version I could get with 32-bit support; if anyone knows how to get latest with 32-bit please shout).

I connected a 1 Terrabyte WD external hard drive and mounted it successfully under /media/WD-External. Formatted as FAT32. I want to explore the possibility of being able to read it from a networked Mac as well. I have also added it to the fstab file so that it mounts automatically at boot via the line: /dev/sdb2 /media/WD-External vfat defaults 0 2

My smb.conf file has this at the end:

[WD-External]
        comment = WD 1TB external HDD
        valid users = <my username here>
        path = /media/WD-External
        available = yes
        read only = no
        browsable = yes
        public = yes
        writable = yes
        write list = <my username here>

I can successfully connect to this drive from a networked Windows 10 computer. I can add it as a network location. I can add as a mapped drive with an assigned letter as well etc. I can browse its contents. I can copy FROM it and drag and drop on my Win10 desktop etc. For the life of me I CANNOT write to it.

When I type: ls -l /media/WD-External the permissions are only set for "root". I ran the chmod command: chmod -R 777 (or other variations here but always starting with a 7) /media/WD-External. The command finishes successfully (silently). However, the ls -l command still shows that root is the only user that can write.

I have also tried adding lines in the smb.conf file directly such as:

create mask = 770
directory mask = 770

but that didn't really work.

Now I have also started exploring the notation with FOUR numbers, not three, but when I do something like chmod 7775 or whatever (while being verbose with -v) I see that each action fails with "Operation not permitted failed to change mode ....etc"

What's going on here? Can anyone suggest a clean way to configure this so that Windows can also write on this drive? Is it the format that's the issue? NTFS perhaps better? Thanks in advance

Organic Marble
  • 23,641
  • 15
  • 70
  • 122
user507866
  • 13
  • 1
    Is the drive mounted when the system starts via an entry in /etc/fstab? If so edit your question and add that information in your original question. – user68186 Sep 15 '19 at 17:14
  • 1
    Why do you use FAT32 filesystem? Use a Unix file system which has a concept of permissions. – vidarlo Sep 15 '19 at 18:01
  • Thank you both for getting back. I have amended my original question regarding fstab. I want fat32 because ideally I'd like this to be visible from my Mac on the network as well. Should I partition instead separately for Win10 and MacOs? Are we sure this is the problem? – user507866 Sep 15 '19 at 18:03
  • You need FAT32 for direct access from MacOS, but not via a network. Then the server will manage the access and you can get access via for example ssh if you install the package openssh-server in your T43. You can log in via the client program ssh and you can transfer files via sftp or scp or via the graphical file browser, if it can manage the ssh protocol. Filezilla should be available too (but I don't know much about MacOS, so I am not sure, what is available). Anyway, I agree with @vidarlo, that you should use a linux file system, for example ext4. – sudodus Sep 15 '19 at 18:37
  • When you access it via Samba, the Mac does not care about the actual file system on the device; it speaks CIFS/SMB to Samba, which has to know the file system. File system would be applicable for block level access, e.g. iSCSI. – vidarlo Sep 15 '19 at 18:42
  • Have a look at this link – sudodus Sep 15 '19 at 18:42
  • You can use samba as well as ssh. Maybe try both and use what you prefer :-) – sudodus Sep 15 '19 at 18:45
  • Thanks guys. I think we are digressing a bit. I have ssh in the server. I have a dual boot MacBook so I’d like to be able to back up general stuff to a network external drive from both OSes. Occasionally, though not so important I’d like to be able to transfer a file or something between the two with ease. Though being a dual boot laptop makes things a bit too tedious anyway and therefore that’s not important. Backing up stuff though is useful. Fat32 I thought would accommodate both OSes without partitioning. I wanted to have a Win10 and a MacOS folder. More important though is windows backups – user507866 Sep 15 '19 at 20:02
  • It feels like with everything that I have done so far is pretty close. I can do everything to this external drive from both Win10 and MacOsX except write. Why? Also, when I’m on the server itself, ie the T43, I can only write to the drive with sudo prefix or directly as root. Not as me. However, I can write on my shared folder in my home directory (ie the T43’s hard drive). How do I get the external WD drive to behave like the shared folder in my home drive? – user507866 Sep 15 '19 at 20:04
  • Sorry. @vidarlo, I missed this somehow, are you suggesting that doing ext4 will help me achieve all I want? Be able to write on the drive from both OSes? – user507866 Sep 15 '19 at 20:11
  • 1
    Yes, ext4 supports real Unix acl's which will allow you to manage permissions. It's never a good idea to run complex server software on an filesystem that does not support native features for that platform. – vidarlo Sep 15 '19 at 20:17
  • Ok. The complex server OS is running on its native hdd (the t43) so I thought the external drive being different wouldn’t be an issue. I’ll try formatting differently and see what happens – user507866 Sep 15 '19 at 20:35
  • as per @vidarlo, I installed the external drive as an ext4 partitioned drive. Worked like a charm... in the end. Still a bit tedious to get it working. Basically what I discovered was: It was easier to create separate subfolders that I want to share under the main directory the external drive was mounted on. Before I was trying to get write access to the /media/ folder which I had made shareable via samba, but that was also the mount location. Even after formatting with ext4 my drive wasn't working. it was actually worse than before, I couldn't even connect. – user507866 Sep 15 '19 at 23:58
  • Creating shareable subfolders within /media/ (after mounting it of course) was easier, i.e. /media//Win10 or ....../MacOs for each OS, did the trick actually. I was able to change permissions for those specific folders, I can do whatever I want once in them without sudo-ing etc. Can map each specific folder to my Windows or Mac system as I please etc. So makes me wonder if that was the issue all along, and this could have worked with Fat32 all along? Can anyone clarify? it would help future users with similar problems. This is easy to miss if it's the only way to do it. – user507866 Sep 16 '19 at 00:03

2 Answers2

2

So makes me wonder if that was the issue all along, and this could have worked with Fat32 all along? Can anyone clarify?

The reason you could not write to the original fat32 based share was not about samba it was about how you mounted the partition.

By default this will mount with root as owner and writeable - everyone else will have read only access. chown and chmod will do nothing on a fat32 or ntfs partition and using create and directory masks in the share definition will not work either on those filesystems.

You needed to specify the permissions required in the fstab statement itself. The permissions on the partition must always be greater than or equal to the permissions required by samba so the fstab line for the partition could have looked like this - where everyone has r/w access then use the samba share definition as the gatekeeper ( valid users ):

/dev/sdb2 /media/WD-External vfat defaults,umask=000 0 2

OR, you could have replaced root as owner with yourself:

/dev/sdb2 /media/WD-External vfat defaults,uid=1000 0 2

OR, you could have done a hybrid making it accessible, readable and writeable only to you:

/dev/sdb2 /media/WD-External vfat defaults,uid=1000,umask=077 0 2

Side Note: In the future it would be better if you use the UUID number ( as in UUID=xxxx-yyyy ) of the partition rather than something like /dev/sdb2. You can find the uuid number by running this command: sudo blkid

Your Followup Questions

-- No, you don't have to add back the "defaults" option. I was just editing your original to show what could be added.

-- Yes, 0027 as a umask would work as well

-- there are 3 ways to specify a device:

/dev/sdxy = this is the way it used to be done but things have grown more complicated over the years and you run the rick that what may be /dev/sda1 on one boot could very well be /dev/sdb1 on another because the system will recognize the second hard drive first when it boots.

UUID number = unique to that partition so it's more reliable. And the pattern changes based on the filesystem. So a fat32 has a xxxx-xxxx pattern, an ntfs has a 16 character pattern, and an ext4 has a 36 character pattern.

LABEL = The Label on that partition - if it has a label.

Morbius1
  • 7,761
  • Thank you, that's a good answer. I reached there already on my own, after some more tedious research online :) But let's compare notes about my approach:

    /dev/sbd2 /media/WD-External ntfs rw,uid=, gid=,umask=0027

    That works. I originally had fat32 and that worked too (maybe with a bit of a different format or options because I research now specifically for ntfs) But yes, finally realised that it was all about the damn thing was mounted.

    I realised that ext4 wasn't appropriate for because if the 15-year old laptop dies, my backups are locked in a format I can't read

     – user507866 Sep 16 '19 at 16:29
  • So, do I really need to add back the "defaults" flag you have there? What is the meaning of the 4-digit numbers of uid? me vs. other users? any harm just having my username? more legible... Also for the mask, my 0027 works right? the equivalent of 750, which was I thought reasonable to go with

    Finally, intrigued by your UUID=xxxx-yyyy suggestion. Do you mean, it's better if for example I connect some other hard drive instead, which the server would try to treat like WD-External? whereas with UUID it only works with that particular USB drive?

     – user507866 Sep 16 '19 at 16:39
  • I edited my original post with possible answers to your other questions. – Morbius1 Sep 16 '19 at 17:19
  • If your laptop dies, it's trivial to access the backups from a VM running Linux, or booting a live session from USB. It's normally better to use native file systems. – vidarlo Sep 16 '19 at 18:06
  • @vidarlo, very interesting actually; didn't think about that. However, I would just prefer the ease of picking up the WD drive and sticking it to an OS that I'm currently using with immediate operability and ease. But definitely something to consider if having an NTFS proves problematic in the future – user507866 Sep 16 '19 at 18:24
0

I've been having similar problems with giving write permissions to external exFAT drives via SMB for months now and I think I finally had a breakthrough, thanks to the answer from @Morbius1.

Solution that worked for me:

  1. Specify write list = root and writeable = yes in /etc/samba/smb.conf. It has to be the root user, as @Morbius1 stated, that one cannot chown the permissions on exFAT filesystems to another user other than root. As it was recommended to create a dedicated user for Samba, I first tried adding a new user pi which wouldn't work, as I couldn't chown the ownership of exFAT files.

  2. Make sure the mount-point has a different name than the Samba share name (e.g. if the mountpoint is /mnt/Media you cannot give the share the name [Media]).

  3. Give the root user a Samba password with smbpasswd -a root.

  4. Restart the Samba service service smbd restart.

  5. Reconnect to your smb and login as root with the password given in 3.

Hope it helps

Quanda Coralle
  • 1