DietPi-Drive_Manager | Samba server: File transfer larger than 4 GB to Mac client fails

[Drew80]

Creating a bug report/issue:

Required Information:

• DietPi version | 6.16
• Distro version | stretch -- 9.5
• Kernel version | Linux pinebox 3.10.105-bsp-1.2-ayufan-77 #1 SMP PREEMPT Sun Jul 9 12:09:30 UTC 2017 aarch64 GNU/Linux
• SBC device | Pine A64 - 1G Kickstarter board (aarch64)
• Power supply used | 5V 2A
• SDcard used | Lexar 4G

Additional Information (if applicable):

• Software title | NZBGet, Sonarr, Radarr, transmission
• software was a fresh install
• yes, I can ca reproduce the issue and have multiple times
• 0ef3b377-6357-4e07-8198-b6525b0350e8 ID

Steps to reproduce:

1. use SD formater to wipe the sd card
2. downloaded image from dietpi.com
3. used etcher (v1.4.4) to write & validate image flashed correctly.
4. insert sd card into Pine64 and wait for DietPi to install & update
5. move dietpi_userdata to mounted USB drive formatted to ext4 & MBR (powered by its own power supply)
6. enable file server samba
7. install NZBGet (149), Sonarr (144), Radarr (145), Transmission (44) & Avahi-Daemon (152) + all additional software required for the above software packages to operate
8. all above software working together
9. copy completed downloaded files from Pine64 to Mac OSX 10.13.6 via connect smb connection

Expected behaviour:

• the connected drive should allow me to copy the files from the Pine64 onto my Mac via the connected smb file share

Actual behaviour:

• Sonarr behaviour
  -- file are being grabbed and sent over to NZBGet and downloaded properly without any issues.
  -- files _ARE ABLE_ to copy from the Pine64 to Mac so far.

• Radarr behaviour
  -- file are being grabbed and sent over to NZBGet and downloaded properly without any issues.
  -- large files (5GB+) _ARE NOT ABLE_ to copy from the Pine64 to Mac.
  -- smaller files (1.18G or less) _ARE ABLE_ to copy from the Pine64 to Mac so far.
  -- error code on Mac is as follows
  The Finder can't complete the operations because some data in "movie1.mkv" can't be read or written (Error code -36)

• Transmission behaviour
  -- not tested yet as newsgroups are my usual method for downloading

Extra details:

I am pulling my hair out here. I think this is some kind of a permissions issues, I'm not sure at all. I have tried changing the permissions of the downloaded files as well with the following:

on the file only - chmod 755
on the file only - chmod 777
on the file & folder chmod 755
on the file & folder chmod 777
changing the user from whatever it was from nzbget to radarr, to sonarr, to dietpi

but nothing seems to work. It's very frustrating. I also tried setting up connecting the Pine64 to the Mac with a network connected folder via the dietpi-drive_manager (Mac to Pine64) but this did not work either and does not make any sense to me as the attached HDD on the Pine64 is about 450G and my Mac has plenty of space to take the files.

The other thing I did do was create a 16GB partition on the external HDD attached to the Pine64 and set it up as the a swap partition. I made the swap file size around 2GB. Writing this out could it be that easy?

Here are all of the file permissions below for all of the folders involved with this issue

_- Parent Folder information_

root@pinebox:/mnt/dietpi_userdata/downloads/complete# ls -al
total 28
drwxrwxr-x  4 dietpi dietpi  4096 Oct 14 22:21 .
drwxrwxr-x 10 dietpi dietpi  4096 Oct 17 18:20 ..
drwxrwxr-x  5 dietpi dietpi  4096 Oct 15 00:34 movies
drwxrwxr-x  8 dietpi dietpi  4096 Oct 17 19:56 tv

_- Sonarr information_
tv shows download directory
root@pinebox:/mnt/dietpi_userdata/downloads/complete/tv

permissions of folders in tv shows directory

root@pinebox:/mnt/dietpi_userdata/downloads/complete/tv# ls -al
total 40
drwxrwxr-x 8 dietpi dietpi 4096 Oct 17 19:56 .
drwxrwxr-x 4 dietpi dietpi 4096 Oct 14 22:21 ..
drwxr-xr-x 2 sonarr dietpi 4096 Oct 17 18:31 series_1
drwxr-xr-x 2 sonarr dietpi 4096 Oct 17 19:56 series_2
drwxrwxr-x 2 dietpi dietpi 4096 Oct 17 18:25 series_3 ** this was changed but still ok
drwxrwxr-x 2 dietpi dietpi 4096 Oct 14 22:35 series_4 ** this was changed but still ok
drwxrwxr-x 2 dietpi dietpi 4096 Oct 17 18:28 series_5 ** this was changed but still ok
drwxrwxr-x 2 dietpi dietpi 4096 Oct 14 23:34 series_6 ** this was changed but still ok

permissions on file in series_1

root@pinebox:/mnt/dietpi_userdata/downloads/complete/tv/series_1# ls -al
total 960148
drwxr-xr-x 2 sonarr dietpi      4096 Oct 17 18:31 .
drwxrwxr-x 8 dietpi dietpi      4096 Oct 17 19:56 ..
-rw-rw-rw- 1 nzbget dietpi 983176931 Oct 16 04:30 series_1_episode_1.mkv

_- Radarr information_
movie download directory
root@pinebox:/mnt/dietpi_userdata/downloads/complete/movies

permissions of folders in movie directory

root@pinebox:/mnt/dietpi_userdata/downloads/complete/movies# ls -al
total 20
drwxrwxr-x 3 dietpi dietpi 4096 Oct 17 21:10 .
drwxrwxr-x 4 dietpi dietpi 4096 Oct 14 22:21 ..
drwxrwxrwx 2 nzbget dietpi 4096 Oct 17 21:01 movie_1

permissions of files in movie_1 folder

root@pinebox:/mnt/dietpi_userdata/downloads/complete/movies/movie_1# ls -al
total 2807992
drwxrwxrwx 2 nzbget dietpi       4096 Oct 17 21:01 .
drwxrwxr-x 3 dietpi dietpi       4096 Oct 17 21:10 ..
-rw-rw-rw- 1 nzbget dietpi     185919 Oct 17 20:50 movie_1.idx
-rw-rw-rw- 1 nzbget dietpi 2844399890 Nov 19  movie_1.mp4
-rw-rw-rw- 1 nzbget dietpi   30775296 Oct 17 20:57 movie_1.sub
-rw-rw-rw- 1 nzbget dietpi       3762 Oct 17 20:50 NPW.nfo

Any help would be great,

Thanks

• Drew

[MichaIng]

@Drew80
Thanks very much for your report.

At first I thought it can't be a permissions issue, since small files are transferred successfully and only large do not. Thought about a limitation of either the Mac file system or samba (config) for files e.g. larger than 4 GB.

On the other hand:

drwxr-xr-x 2 sonarr dietpi

Sonarr seems to create files with 755 permissions, which leads so samba user (which is "dietpi") should not be able to write/delete those files at least. So transferring to Mac should work (read access), but changing the files from Mac client should not. We need to convince sonarr (possibly also radarr/lidarr) to create files with 775 permissions to allow write access for samba and other software at best.

• Or is it better anyway to not change files grabbed by sonarr from outside? Not sure how it handles internal database e.g. that external changes might break sonarr internal handling?

So but your issue is actually with radarr, not sonarr. All files I see there so far are (still) owned by nzbget. Owner does not seem to be changed, when sonarr/radarr grab files from nzbget? However permissions look fine, all of them are group "dietpi" with 77X/66X permissions, which should be sufficient for samba to access.

So finally, I am again at the top argumentation: Since all permissions should allow samba read access, in case of affected radarr even write access, and you anyway played around with permissions, those should not be the issue. You could verify the 4 GB limit by testing with a file a bid smaller and a bid larger then that.

But we will also have a look into your bug report to verify settings again.

[Fourdee]

@Drew80

Thanks for the report Drew 👍

large files (5GB+) ARE NOT ABLE to copy from the Pine64 to Mac.

Interesting, 32bit/FAT limitation? Is the Mac 64bit system + OS?

Also what filesystem are you transferring from Pine to Mac OS, Pine is ext4, Mac is?

/dev/sda1: UUID="x" TYPE="ext4" PARTUUID="59ad935f-01"
/dev/sda2: UUID="x" TYPE="ext4" PARTUUID="59ad935f-02"

[Fourdee]

I'll setup a pine and see if I can replicate SMB to windows (don't have a Mac).

[Drew80]

@MichaIng

You could verify the 4 GB limit by testing with a file a bid smaller and a bid larger then that.

I copied over 2 files, file_1.m4v (4.21GB) and file_2.m4v (3.95GB) using the smb connection and connected with user dietpi to the share from my mac to the pine64

On my mac selected both files dragged and dropped below is the behaviour of both files.

• file_1.m4v
  -- gets the same error as I listed above
  The Finder can't complete the operations because some data in "file_1.m4v" can't be read or written (Error code -36)

• file_2.m4v
  -- copied over fine (mac to pine64) or so I thought --> continue reading

-- original permissions on the file were
-rwxrw-r-- 1 dietpi dietpi 0 Oct 18 12:26 file_2.m4v

-- changed them to
-rw-rw-rw- 1 nzbget dietpi 0 Oct 18 12:11 file_2.m4v

-- Here is where I realized the file had no size --> did not notice the first time
-rwxrw-r-- 1 dietpi dietpi 0 Oct 18 12:26 file_2.m4v

I will try again later with a smaller file size to see where the "magic number" seems to be.

[Drew80]

@Fourdee

Interesting, 32bit/FAT limitation? Is the Mac 64bit system + OS?

Also what filesystem are you transferring from Pine to Mac OS, Pine is ext4, Mac is?

My mac is a 64 bit machine

Drew@Drews-Mac-Pro:~$ uname -m
x86_64

The OS is macOS High Sierra version 10.13.6
The filesystem on the mac is APFS

Drew@Drews-Mac-Pro:~$ diskutil info disk1s1
   Device Identifier:        disk1s1
   Device Node:              /dev/disk1s1
   Whole:                    No
   Part of Whole:            disk1

   Volume Name:              Macintosh HD
   Mounted:                  Yes
   Mount Point:              /

   Partition Type:           41504653-...removed
   File System Personality:  APFS
   Type (Bundle):            apfs
   Name (User Visible):      APFS
   Owners:                   Enabled

   OS Can Be Installed:      Yes
   Booter Disk:              disk1s2
   Recovery Disk:            disk1s3
   Media Type:               Generic
   Protocol:                 PCI
   SMART Status:             Verified
   Volume UUID:              05783C50-....removed 
   Disk / Partition UUID:    05783C50-...removed

   Disk Size:                449.7 GB (449650339840 Bytes) (exactly 878223320 512-Byte-Units)
   Device Block Size:        4096 Bytes

   Volume Total Space:       449.7 GB (449650339840 Bytes) (exactly 878223320 512-Byte-Units)
   Volume Used Space:        221.4 GB (221351915520 Bytes) (exactly 432327960 512-Byte-Units) (49.2%)
   Volume Free Space:        228.3 GB (228298424320 Bytes) (exactly 445895360 512-Byte-Units) (50.8%)
   Allocation Block Size:    4096 Bytes

   Read-Only Media:          No
   Read-Only Volume:         No

   Device Location:          Internal
   Removable Media:          Fixed

   Solid State:              Yes
   Hardware AES Support:     No

[MichaIng]

APFS

https://en.wikipedia.org/wiki/Apple_File_System:

Max. file size | 8 EiB (2²³ bytes)

So file size is definitely not a limitation on the new Apple file system. We could do some web research to check how well samba works with this (quite new) file system client side, or if the MacOS samba client itself has limitations.

Fourdee already runs the test for Pine64 => Windows, to sort out either Pine64, DietPi samba server or system is the reason.

[Fourdee]

@MichaIng

Fourdee already runs the test for Pine64 => Windows, to sort out either Pine64, DietPi samba server or system is the reason.

Setting it up now, will report back later or tomorrow.

[Fourdee]

@Drew80

Please try connecting the Samba share with CIFS, as per the answer to:
https://discussions.apple.com/thread/5804160?answerId=5804160021#5804160021

Please let us know if 4GB> files are reported as the correct size, and, transferable back to Mac.

[Fourdee]

Notes:

• ARMhf?

2018-10-18 23:32:04 (7.87 MB/s) - ‘package.run’ saved [27598601/27598601]

Installer for nzbget-20.0
Verifying package...
Checking system...
CPU-Architecture: armhf
Unpacking...
Configuring...

• https://github.com/nzbget/nzbget/issues/35

[Drew80]

@Fourdee

Please try connecting the Samba share with CIFS, as per the answer to:
https://discussions.apple.com/thread/5804160?answerId=5804160021#5804160021

Please let us know if 4GB> files are reported as the correct size, and, transferable back to Mac.

I loaded up file_1 & file_2 onto a USB stick and got them onto the Pine64 without any issues. I also changed all of the permissions to match what we've had them set at before nzbget:dietpi and chmod of 666

From my mac i connected to the Pine64 using
cifs://<ip_of_pine64>

It connected ok but it still would not let me transfer either of the files using the my mac connected to the pine64 via a cifs or smb connection

still no working solution as of yet on my end

[Fourdee]

@Drew80

Thanks for trying Drew.

Ok test with following:

root@DietPi:~# chmod 666 /mnt/dietpi_userdata/test.file
root@DietPi:~# ls -lha /mnt/dietpi_userdata/test.file
-rw-rw-rw- 1 nzbget dietpi 5.0G Oct 19 09:52 /mnt/dietpi_userdata/test.file

🈯️ Transfers fine.

I'am unable to test a NZBGET download, lack newzbin sub. However, I believe the issue is NZBGET running under a 32bit binary, and, limiting downloaded files to 4GB< size.

@Drew80

We can confirm this by making a test 5G file:

dd if=/dev/zero of=/mnt/dietpi_userdata/test.file bs=1G count=5
chown nzbget:dietpi /mnt/dietpi_userdata/test.file
chmod 666 /mnt/dietpi_userdata/test.file

• Then try to transfer the file over Mac
• Also check the file size of test file with ls -lha /mnt/dietpi_userdata/test.file.
• -rwxrw-r-- 1 dietpi dietpi 0 Oct 18 12:26 file_2.m4v 0 byte file, failed to extract?

[Fourdee]

@Drew80

Also, in the NZBGET GUI, check the messages tab + errors, for extraction/download issues.

[MichaIng]

Can it be, that the binary build arch limits file sizes it can handle? I though this is always just a matter of the underlying OS + file system, how large files it can allocate.

Also: https://nzbget.net/installation-on-linux

• It should detect the correct architecture automatically, thus on Pine64 it should be arm64.
• Debian repo also has a arm64 version: https://packages.debian.org/stretch/nzbget

It can be also checked, which arch the installer supports:
sh nzbget-latest-bin-linux.run -h
Then force wanted arch, if somehow it was not detected correctly:
sh nzbget-latest-bin-linux.run --arch arm64

Will check this.

---

Indeed no explizite arm64 support:

root@VM-Stretch:/tmp# sh nzbget-latest-bin-linux.run -h
Installer for nzbget-20.0

This installer supports Linux kernel 2.6 or newer and the following CPU architectures:
    i686     - x86, 32 or 64 Bit
    x86_64   - x86, 64 Bit
    armel    - ARMv5/v6 (ARM9 and ARM11 families)
    armhf    - ARMv7/v8 (Cortex family)
    mipsel   - MIPS (little endian)
    mipseb   - MIPS (big endian)
    ppc6xx   - PowerPC 6xx (603e series)
    ppc500   - PowerPC e500 (core e500v1/e500v2)

• But armhf - ARMv7/v8 (Cortex family), if not just upwards compatible x32.

---

It could be tested if it works with the Debian arm64 package: https://deb.debian.org/debian/pool/main/n/nzbget/nzbget_17.1+dfsg-3_arm64.deb

• NB: It's just v17.1 instead of v20

[Drew80]

@Drew80

Also, in the NZBGET GUI, check the messages tab + errors, for extraction/download issues.

No errors in the Errors tab under the messages in the NZBGet messages tab

[Drew80]

@Fourdee
@MichaIng

_SUCESS!!!!_

I did a bunch of google-foo and found this on the Raspberry Pi website.
https://www.raspberrypi.org/forums/viewtopic.php?t=26826

Netatalk install the Apple File Protocol which is Apples version of Samaba

Samba share
smb://192.168.1.1

Apple File Protocol
afp://192.168.1.1

I followed the steps which were basically

Installation:
sudo apt-get install netatalk

Stop the service:
sudo /etc/init.d/netatalk stop

Configuration:
sudo nano /etc/netatalk/AppleVolumes.default

all the way at the bottom of the file add the following to the :DEFAULT: line
rw

# The line below sets some DEFAULT, starting with Netatalk 2.1.
:DEFAULT: options:upriv,usedots,rw

then add the directory you want to share. The label in "quotes" will be what it is called on out mac when you mount it

# By default all users have access to their home directories.
~/                      "Home Directory"
/mnt/dietpi_userdata    "Media"

Start netatalk
sudo /etc/init.d/netatalk start

and you are good to go.

I've successfully transferred a bunch of files over the 4GB size. I even just dragged and dropped 14GB (multiple files) in one go

I would say this fixes most of the issues. I even uninstalled all of the DietPi's preloaded file servers samba and the samba in the drive manager. Everything is on run through netatalk.

The only issue I have to run this completely headless is the permissions.

Since you login to the AFP with the dietpi user & password they are the ones that have the permissions. I can take files off (pine64 to mac) and put them on (mac to pine64) which won't happen every often if at all.

The issue is file management. Once the files are off the Pine64 I would like to be able to delete them & the folders from my mac. However I can't because of the users & groups. Sonarr, radarr & nzbget all have users and are not dietpi. I am not very linux-y and usually I just read a ton and try stuff. However when ever I get to permissions things usually go south. Any ideas on where to change the users from sonarr, radarr & nzbget to dietpi? This would probably solve a bunch of problems with other sharing permissions as well.

Also with the installation of netatalk a lot of the packages needed to install it where already installed with dietpi. Not sure if that is because samba was installed or what but it would be a great addition to the preloaded dietpi file server options for mac users.

[Drew80]

@Fourdee
Still want me to test these with the AFP working?

root@DietPi:~# chmod 666 /mnt/dietpi_userdata/test.file
root@DietPi:~# ls -lha /mnt/dietpi_userdata/test.file
-rw-rw-rw- 1 nzbget dietpi 5.0G Oct 19 09:52 /mnt/dietpi_userdata/test.file

We can confirm this by making a test 5G file:

dd if=/dev/zero of=/mnt/dietpi_userdata/test.file bs=1G count=5
chown nzbget:dietpi /mnt/dietpi_userdata/test.file
chmod 666 /mnt/dietpi_userdata/test.file

• Then try to transfer the file over Mac
• Also check the file size of test file with ls -lha /mnt/dietpi_userdata/test.file.
• -rwxrw-r-- 1 dietpi dietpi 0 Oct 18 12:26 file_2.m4v 0 byte file, failed to extract?

[MichaIng]

@Drew80
AFP works with Apple, but the new APFS Apple file system actually started to support SMB/CIFS (if I read this correctly) with the aim to replace AFP. It is still supported but should not be long anymore. So I suggest to directly setup SMB/CIFS.

But yeah if with Apple+samba, either via smb or cifs, uploads > 4GB does not work, then stay with AFP. Although I would keep investigation how to solve this with standard samba as well.

About backwards permissions:
With what permissions are files created on the AFP share? I guess it is similar to samba, that by default it is 644 (or 755) and for sonarr/radarr/nzbget users to allow write/removal it needs to be 664 (or 775).
Check the documentation in how to achieve this.
€: Try this: https://superuser.com/a/683807
0775 would be it to allow all other users at least read permissions, if required.

[Drew80]

@MichaIng

But yeah if with Apple+samba, either via smb or cifs, uploads > 4GB does not work, then stay with AFP. Although I would keep investigation how to solve this with standard samba as well.

I have another pine and other external HDDs as well. If you guys need me to I am more than happy to do testing and post logs to help solve the issue for future releases. With installing the AFP at least mac users have a solution when trying to get dietpi and their mac working together.

_Please advise about additional testing with regarding the pine64 & mac samba sharing (or any other mac related issues)_
I'd love to try and give back to the DietPi community. It's my go to OS for my SBC projects.

About backwards permissions:
With what permissions are files created on the AFP share? I guess it is similar to samba, that by default it is 644 (or 755) and for sonarr/radarr/nzbget users to allow write/removal it needs to be 664 (or 775).
Check the documentation in how to achieve this.
€: Try this: https://superuser.com/a/683807
0775 would be it to allow all other users at least read permissions, if required.

I made a test file (test file.txt) on my mac using textEdit (basic mac text editor) and dropped it on to the pine64. The file had the dietpi:dietpi user & group associated to it. I was able to complete the following without any issues:

• edit the file located on the pine64 using textEdit (mac program) on my Mac desktop
• edit the file via ssh in terminal using nano
• delete the file from the pine64 using my mac desktop, keyboard & mouse.

root@pinebox:/mnt/dietpi_userdata/downloads/complete# ls -l
total 20
drwxrwxr-x 8 dietpi dietpi 4096 Oct 20 14:54 movies
-rw-r--r-- 1 dietpi dietpi   53 Oct 21 11:53 testfile.txt
drwxrwxr-x 9 dietpi dietpi 4096 Oct 20 15:35 tv

[Fourdee]

@Drew80

I'd love to try and give back to the DietPi community. It's my go to OS for my SBC projects.

Many thanks for offering your support, assistance and time, we really appreciate it 👍

Just wondering if the Mac is incorrectly getting the filesystem type data from the Pine over SMB, maybe it thinks or treats ext4 as FAT?

Any ideas on where to change the users from sonarr, radarr & nzbget to dietpi?

The permissions are set in the service files, however, by changing them to "dietpi", you are giving them much more permissions than what some would consider "acceptable". Also, any updates for the software titles our end, would overwrite the service files with their lower priv users, negating any changes you make.

We previously ran everything under "root" to avoid any filesystem permissions, however, as above, security took priority.

A simple solution may be to allow root login on the AFP file server. However, no idea if this is possible yet, requires research.

Also @Drew80, another test is to try and force SMB version 1/2/3 during Mac connection:

http://hints.macworld.com/article.php?story=20131122083837447

[MichaIng]

@Drew80
Thanks for your effort and report. Jep for now AFP is a solution, which we could implement into dietpi-drive_manager (client) and dietpi-software (server/share) as well, as long as we don't find any solution for smb/cifs + Mac.

-rw-r--r-- 1 dietpi dietpi 53 Oct 21 11:53 testfile.txt

There you have the permission issue, it's 644 by default when files created on the Mac. To allow sonarr/nzbget modifying/removing the files, it needs to be 664 or 775, which is then a safer solution that running sonarr/nzbget as dietpi user.

Quick search: http://netatalk.sourceforge.net/3.1/htmldocs/afp.conf.5.html

• Try to add to the afp.conf, which should be placed

file perm = 0775
directory perm = 0775
umask = 0002

€: This is netatalk v3.X, Stretch repo ships v2.2: http://netatalk.sourceforge.net/2.2/htmldocs/AppleVolumes.default.5.html

• Try to add perm=0775 umask=0002 to the end of the /mnt/dietpi_userdata "Media" line inside /etc/netatalk/AppleVolumes.default.

€: @Fourdee
Whoopsie, was in writing when yours appeared 😆. Moreless the same, jep better use perm/mask settings as above then run software as user with full permissions.

[Fourdee]

@MichaIng

Whoopsie, was in writing when yours appeared

No worries, 1.5 brains are better than 0.5 (0.5 = me today) 😉 👍

[MichaIng]

@Fourdee
Test, strange, I get messages about a (repeated) new issue per mail, which is not there when opening GitHub and as well your answer, which I can't see here now. Does GitHub have temporary issues on saving posts/issues etc?

€: Strange, now I see your post at least. Did you get the notification from dezren39 reporting an install issue with docker? I have 5 separate ones, obviously unsuccessfully created.
@dezren39
If you see the mention, try again your report at best tomorrow. I least I could test docker install on my Stretch VM, which went fine. Further investigation required, also the failed bug report :thinking:. However off topic here... Hmm emojis and mentioned users also do not pop up as expected. Time to sleep and check back tomorrow...

[Fourdee]

@MichaIng

new issue per mail, which is not there when opening GitHub and as well your answer, which I can't see here now. Does GitHub have temporary issues on saving posts/issues etc?

Yep, was getting the same yesterday. Also, commits were not being update on this site for 4+ hours after they were sent.

GitHub having issues, still.

[dezren39]

Yeah appears to be a Github issue. Status.github.com reports data issues. I'll try again tomorrow. :-) Thanks.

---

From: MichaIng [e-mail]
Sent: Sunday, October 21, 2018 7:55:33 PM
To: Fourdee/DietPi
Cc: Drewry Pope; Mention
Subject: Re: [Fourdee/DietPi] Permission with network mounted drives (#2149)

@Fourdeehttps://github.com/Fourdee
Test, strange, I get messages about a (repeated) new issue per mail, which is not there when opening GitHub and as well your answer, which I can't see here now. Does GitHub have temporary issues on saving posts/issues etc?

€: Strange, now I see your post at least. Did you get the notification from dezren39 reporting an install issue with docker? I have 5 separate ones, obviously unsuccessfully created.
@dezren39https://github.com/dezren39
If you see the mention, try again your report at best tomorrow. I least I could test docker install on my Stretch VM, which went fine. Further investigation required, also the failed bug report 🤔. However off topic here... Hmm emojis and mentioned users also do not pop up as expected. Time to sleep and check back tomorrow...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Fourdee/DietPi/issues/2149#issuecomment-431718327, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AKtJ5sPbH9bbv5jFR9pTcvcqgW8qGRp5ks5unReFgaJpZM4Xsl8E.

[Drew80]

@Fourdee

Just wondering if the Mac is incorrectly getting the filesystem type data from the Pine over SMB, maybe it thinks or treats ext4 as FAT?

This is what I could find. it shows it as afpfs - AppleFileProtocol File system. So i think it sees the mount as an AFP. I don't think I can check to see what it thinks the HDD file system is. It can see what the windows partition (I run boot camp when I need to) as a NTFS file system. From what I read (quickly) online I can not get info about the filesystem of mounted HDD, just the share connection, afp, smb, etc.

Drew@Drews-Mac-Pro:~$ mount
/dev/disk1s1 on / (apfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
/dev/disk1s4 on /private/var/vm (apfs, local, noexec, journaled, noatime, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
/dev/disk0s3 on /Volumes/.Windows8 (ntfs, local, read-only, noowners)
//[email protected]/Pine%20Box on /Volumes/Pine Box (afpfs, nodev, nosuid, mounted by Drew)

Also @Drew80, another test is to try and force SMB version 1/2/3 during Mac connection:

http://hints.macworld.com/article.php?story=20131122083837447

I will try and test that this week / weekend. I'd like to find my other Pine64 1G board and get it up and running so I don't have to keep messing with my somewhat working version of my dl'ing machine, I'll just have to find it first. 😄

Yep, was getting the same yesterday. Also, commits were not being update on this site for 4+ hours after they were sent.

GitHub having issues, still.

I thought I was going crazy because I had to post the info about the APF and netatalk twice. Glad to hear it wasn't me

[Drew80]

@MichaIng

€: This is netatalk v3.X, Stretch repo ships v2.2: http://netatalk.sourceforge.net/2.2/htmldocs/AppleVolumes.default.5.html

Try to add perm=0775 umask=0002 to the end of the /mnt/dietpi_userdata "Media" line inside /etc/netatalk/AppleVolumes.default.

I will also try this this week, hopefully when setting up my other pine64 board to do future testing for mac - dietpi connections with smb, cifs file system sharing.

[Drew80]

@MichaIng

Try to add perm=0775 umask=0002 to the end of the /mnt/dietpi_userdata "Media" line inside /etc/netatalk/AppleVolumes.default.

I ended up changing from NZBGet to Sabnzbd. I know have no really permission issues with moving & deleting files from the AFP share. Looks like there might be some issues with radarr, sonarr & nzbget playing nice with the permissions. So I did not add that to the AppleVolumes.default file

[Drew80]

@Fourdee @MichaIng

I found my other Pine64 board. I have a fresh install of DietPi OS and upgraded to 6.16. Here is what I did.

fresh install on 16GB ADATA micro SD class 10 card
Setup on Pine64

1. Diet-Pi Config
   
   
   
   • 4 Advanced Options
     
     
     
     
     
     • Time sync mode - Daemon + Drift —> read that this helps with VPN issues
     
     
     
   
   
   • 5 Language/Regional Options
     
     
     
     
     
     • Locale —>en_US.UTF-8
     
     
     
     • Timezone —> America —> Edmonton
     
     
     
   
   
2. Software Additional
   
   
   
   • 152 —> Avahi-Daemon
   
   

Setup on Mac
Use router to set static IP for SSH

on Pine find mac address

-bash: ifconfig: command not found

What gives here?
Maybe a possible bug?
Found it via
cat /sys/class/net/eth0/adress

So where would we like to go from here?

Test samba with larger files? Please let me know what setting we want to check.

[MichaIng]

@Drew80

ifconfig

• bash: ifconfig: command not found

ifconfig is part of the obsolete net-tools package, which we don't pre-install on DietPi anymore.
Use the iproute2 commands instead, e.g. ip a to show interface details.

[MichaIng]

SABnzbd might bring permission issues actually since we forgot to make it run as dietpi group with 775 until recent v6.17 commit: https://github.com/Fourdee/DietPi/issues/2172

To verify the 4GB Mac issue with smb/cifs you could retry with the other Pine64, but high likely it is just the same. Would be indeed an idea to test it with different smb versions, who knows.

You mentioned above that on Mac the AFP mount file system shows as APFS. I am not 100% sure but guess it is expected in case of smb/cifs/afp that that file system always just matches the local machines file system. Since it supports cross OS shares, it makes sense that the servers file system info cannot be ported to the client.

[Fourdee]

Ticket appears dead, will mark as closed.

@Drew80 If this is still an issue/unresolved, please reopen.