Re: SAMBA Problems

On 2/19/25 1:27 AM, c186282 wrote:

On 2/18/25 8:49 PM, Lawrence D'Oliveiro wrote:

On Tue, 18 Feb 2025 02:59:35 -0500, c186282 wrote:
>

SAMBA isn't anything NEW - it SHOULDN'T be this difficult.

>
It isn’t. I find when I test things with smbclient, they usually work.
>
It’s invariably the Windows clients that cause problems.

    In this exact case, it's Linux clients.
    Tried and tries, checked smb,conf against recent
   examples, checked /etc/groups, checked permissions
   and ownership. Just WON'T work.
    As said, I used SAMBA in a mixed environment for
   many many years. Then, decidedly by bookworm,
   SOMETHING nasty changed. This is terrible.
    Did NFS shares instead. Don't love NFS, SAMBA
   offers much more fine-grained options and
   more nuanced security. If this was a work
   environment I'd be even more upset - but
   this is a 'home' system now that I've retired
   and Vlad probably ain't looking.
    Anyway, a root @reboot runs a script that mounts
   the /dev/sdx USBs. They DO show up where they
   are supposed to be. Liberal permissions. SAMBA
   just CAN'T share them properly, nothing but
   permission errors on the client no matter how I
   set things - and I've used Linux since 'X' was
   introduced (no fun setting mouse/keyboard/mon
   back then) on floppies.
    Dunno WHAT the hell they changed, but it's not
   documented worth a damn.

followup :
   DID have to do it all with NFS alas.
   Root crontab @reboot, after a safe delay, mounts
   the USB drives into local subdirs.
   @reboot sleep 100 && /root/scripts/mountUSB.sh &
     #!/bin/bash
     # mount the external USBs
     sleep 10
     mount -t ext4 /dev/sdb1 -o defaults /home/nas/share/MyShare1
     mount -t ext4 /dev/sdc1 -o defaults /home/nas/share/MyShare2
   /etc/exports has the proper NFS share defs. Note
   that the syntax can be fiddly.
     /home/nas/share/MyShare1 192.168.0.0/24(rw)
     /home/nas/share/MyShare2 192.168.0.0/24(rw)
   All clients have the proper /etc/fstab mount defs.
     192.168.0.123:/home/nas/share/MyShare1 /mnt/shar1 nfs defaults,timeo=900,retrans=5,_netdev 0 0
     192.168.0.123:/home/nas/share/MyShare2 /mnt/shar2 nfs defaults,timeo=900,retrans=5,_netdev 0 0
   Root crontab runs a backup bash script twice a day.
   The USB drives all have a tag file - "USB-Mounted" -
   on them. The script makes sure it's there. If so
   then it's "rsync -a --delete <whatever>/ <wherever>".
   Pretty quick. Appends the datetime and 'ok' to a
   log file. If the tag file is NOT found then it
   appends the datetime with "fail" to the log.
     5 6,18 * * * /root/scripts/dupSDB1.sh
     #!/bin/bash
     # use rsync to copy sdb1 (samsung ssd) to sdc (wd black)
     # when run, it will do rsync and append 'backups.log'
     # with either the success datetime OR the datetime
     # with 'fail' afterwards.
     # our test file - if not there then usb
     # is not properly mounted
     FILE=/home/nas/share/MyShare1/USB-Mounted
     if test -f $FILE ; then
       rsync -a --delete /home/nas/share/MyShare1/ /home/nas/share/MyShare2
       echo "backup done"
       dt=$(date)
       dt2=${dt}" ok"
       touch /home/nas/backups.log
       echo $dt2 >> /home/nas/backups.log
     else
       dt=$(date)
       dt2=${dt}" fail"
       touch /home/nas/backups.log
       echo $dt2 >> /home/nas/backups.log
     fi
   Early morning, root crontab reboots the whole box.
     0 1 * * * /sbin/shutdown -r +1
   It works, it's easy, not even any Python or 'C'.
   Quick improvement, test for the "USB-Mounted" on
   the proposed mirror drive as well, to be sure.
   Client NFS connections SEEM to hold thru a reboot
   of the NAS - at least if it's not TOO lengthy.
   Auto-backups MIGHT want to run a 'mount -a' though
   just to be sure.
   Set the usb SSD as the prime backup point since
   it's a bit faster. For now the mirror is a WD
   Black magnetic. Decided against softRAID.
   This NAS runs on the latest MX Linux. You'll
   rarely go wrong with MX.