Re: Update on problem mounting NFS share
On 10/5/23 05:01, Steve Matzura wrote:
On 10/4/2023 2:32 PM, David Christensen wrote:
On 10/4/23 05:03, Steve Matzura wrote:
On 10/3/2023 6:06 PM, David Christensen wrote:
On 10/3/23 12:03, Steve Matzura wrote:
I gave up on the NFS business and went back to good old buggy
but reliable SAMBA (LOL), ...
I have attempted to document the current state of Samba on my
SOHO, below. ...
Wow but that's an awful lot of work for something that seems to
be a timing problem. But at least I learned something.
What is posted is the results of a lot of work -- trying countless
combinations of settings on the server and on the client via edit,
rebooting, and test cycles; until I found a combination that
seems to work.
Your OP of /etc/fstab:
//192.168.1.156/BigVol1 /mnt/bigvol1 civs vers=2.0,credentials=/root/smbcreds,ro
* The third field is "civs". Should that be "cifs"?
* The fourth field contains "ro". Is that read-only? If so, how
do you create, update, and delete files and directories on
/mnt/bigvol1?
The 'civs' is indeed cifs. That was hand-transcribed, not
copied/pasted. My bad.
Please "reply to List".
Please using inline posting style.
Copy-and-paste can require more effort, but precludes transcription
errors. On the Internet, errors are not merely embarrassing: they can
cause confusion forever.
I mount the drive read-only because it
contains my entire audio and video library, so anyone to whom I give
access on my network must not ever have the slightest possibility of
being able to modify it.
So, you create, update, and delete content via some means other than
/mnt/bigvol1 (?).
TIMTOWTDI for multiple-user Samba shares.
ACL's would seem to be the canonical solution, but they introduce
complexities -- Unskilled users? Usage consistency from Windows
Explorer, Command Prompt, Finder, Terminal, Thunar, Terminal Emulator,
etc.? Unix or Windows ACL's? Backup and restore? Integrity auditing
and validation?
I chose to implement a "groupshare" share with read-write access for all
Samba users and a social contract for usage (I also implemented a
"groupshare" group/user and configured Samba to force ownership of content):
2023-10-05 11:51:52 toor@samba ~
# cat /usr/local/etc/smb4.conf
[global]
local master = Yes
netbios name = SAMBA
ntlm auth = ntlmv1-permitted
passdb backend = tdbsam
preferred master = Yes
security = USER
server string = Samba Server Version %v
wins support = Yes
workgroup = WORKGROUP
<redacted>
[dpchrist]
force user = dpchrist
path = /var/local/samba/dpchrist
read only = No
valid users = dpchrist
<redacted>
[groupshare]
create mask = 0777
directory mask = 0777
force create mode = 0666
force directory mode = 0777
force unknown acl user = Yes
force user = groupshare
path = /var/local/samba/groupshare
read only = No
2023-10-05 11:54:48 toor@samba ~
# grep groupshare /etc/group /etc/passwd
/etc/group:groupshare:*:999:
/etc/passwd:groupshare:*:999:999:Groupshare:/home/groupshare:/usr/sbin/nologin
2023-10-05 12:00:55 toor@samba ~
# find /var/local/samba/ -type d -depth 1 | egrep 'dpchrist|groupshare'
| xargs ls -ld
drwxrwxr-x 98 dpchrist dpchrist 102 Oct 3 14:13
/var/local/samba/dpchrist
drwxrwxr-x 8 groupshare groupshare 13 Oct 5 11:32
/var/local/samba/groupshare
Debian client:
2023-10-05 11:45:42 root@taz ~
# egrep 'dpchrist|groupshare' /etc/fstab | perl -pe 's/\s+/ /g'
//samba/dpchrist /samba/dpchrist cifs
noauto,vers=3.0,user,username=dpchrist 0 0
//samba/groupshare /samba/groupshare cifs noauto,vers=3.0,user 0 0
By the way, another friend to whom I showed my problem came up with a
similar solution surrounding my original hypothesis that there is a
delay between the time fstab is processed and networking is
available. He said he tested it probably a dozen times and it worked
every time. His suggested fstab line is this:
//192.168.1.156/BigVol1 /mnt/bigvol1 cifs vers=3.1.1,credentials=<credentials-file>,rw,GID=1000,uid=1000,noauto,x-systemd.automount
It's a matter of edit-reboot-test cycles with a consistent and complete
test protocol.
"GID=1000,uid=1000" -- looks similar to my "groupshare" idea, but from
the client side. That should produce the same results for most use-cases.
"credentials=<credentials-file>,noauto,x-systemd.automount" -- I assume
this is a work-around for unreliable mounting at system start-up (?). I
tried similar tricks, and ended up going back to KISS -- typing mount(8)
commands by hand once per boot.
David
Reply to: