0

Running a pc with Linux Mint 20.1 and Fedora 34, a share from the Linux Mint machine could be accessed on the Fedora machine. After updating Fedora to 35, share ceased being accessible from the Fedora machine, with a variety of errors I did not record at the time.

The share was still accessible from Windows machines on the network for a period(All Win10). However the OS drive on the machine was failing(failing disk health checks and a lovely clicking noise), which prompted a physical replacement of the OS drive. The drive on which the share exists was not replaced or changed.

Installed Linux Mint 21.1 on the machine, and restored the smb.conf file to /etc/samba.

Post reinstall of Linux Mint with 21.1, share is not accessible via Windows pc's on the network or the Fedora 35 machine. Access denied error is received on Windows with the seemingly similar error of mount error 13 = Permission denied on the Fedora machine.

The smb.conf on my Linux Mint machine did not change(or rather I reloaded a backed up version of it), nor did the fstab configuration on my Fedora 35 machine. Configs are below, with smb.conf entries first.

[Share1$]
   comment = Old Share
   path = /mnt/Share1
   browseable = yes
   read only = no
   guest ok = no
   valid users = yeetus

Fstab entry is this:

//192.168.1.12/Share1$/ /mnt/Share1/ cifs iocharset=utf8,file_mode=0777,dir_mode=0777,user=yeetus,noperm 0 0

I've tried adding the version argument as well as the sec option to the fstab entry, in a variety of combinations. I have also tried defining the workgroup and domain, with no change in results.

ls -la on the folder to be shared shows this:

drwxrwxrwx  1 root  root  24576 Sep  2 13:54 Share1

Which is odd, as I previously tried to assign yeetus as the owner of the directory.

Permissions were set on the parent folder as well and looked like this:

drwxrwxrwx  4 yeetus yeetus  4096 Sep  2 14:25 .

To my knowledge, besides the update of the OS on the Fedora system and the installation of a new instance of Linux Mint on the other, nothing I can find has changed.

Any thoughts on why I might be plagued with thie access/permission denied error? My original belief was that it was Fedora related, since I lost access there first, but I no longer believe this is the case as the Windows machines on the network cannot access the share either.

Edit:

As requested, output of mount -vvv -t below.

mount -vvv -t cifs//192.168.1.12/Share1$/ /mnt/Share1/
mount: /mnt/Share1: unknown filesystem type 'cifs//192.168.1.12/Share1$/'.

File system being mounted is a luks encrypted volume that is mounted on the Linux Mint machine. My recollection is that NTFS was the contained file system upon encryption, as a good number of Windows machines would be using the share.

5
  • Add the output of mount -vvv -t cifs//192.168.1.12/Share1$ /mnt/Share1/ to the question. Sep 4, 2022 at 0:33
  • The above comment didn't have one, but you might be right, let me check. Edit: Yes, it needed a space. Same output as before, error 13. – Sep 4, 2022 at 6:13
  • Output from -vvv was the same short error message. Credentials are correct, I am entering them by hand each time and I am certain of them. I've never, to my recollection, had to allow client I.P.'s before. Did something change where I now have to do this? Sep 4, 2022 at 6:17
  • 1. If you replaced the os disk you may need to use smbpasswd to recreate the samba user accounts and set their passwords Sep 4, 2022 at 6:22
  • 2. You will get poor performance if the underlying filesystem used on the samba server is NTFS. Your rationale about samba clients being Windows has no bearing at all. What happens is that samba emulates NTFS network shares on top of a Linux filesystem. In the case of NTFS that's not native so there's yet another layer of emulation and conversion Sep 4, 2022 at 6:24

1 Answer 1

1

Issue was simply forgetting that smbpasswd needed to be set. It had been so long since I setup the system that I forgot to re-add this.

1
  • So that's was a credentials problem ... on server side !
    – Archemar
    Sep 4, 2022 at 8:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .