5

I would like to move/share some files between Linux and OpenBSD. What would be an easy and simple way to achieve this?

These are the solutions I have found so far and why I am not fully convinced:

  • Using a normal USB drive with a FAT32 partition: It won't preserve permissions.
  • Using another partition type: Which one would work RW on both?
  • Using tar: I am worried about the fact that the tar implementations differ between the BSDs and Linux.

What would be a simple way to share files between Linux and OpenBSD while keeping permissions and timestamps?

Improve this question

5 Answers 5

Reset to default
3

I'm using NFS mounts. I have my /home mounted on both Ubuntu and OpenBSD, from an OpenBSD NFS server and have no issues (same UID/GID on both systems!).

If you are dual-booting and just want to transfer a few files every now and again, tar archives on a FAT32 USB stick will work just fine.

I've never tried to share partitions between Linux and OpenBSD (I'd use virtual machines instead of dual-booting). That sounds tricky, but OpenBSD 6.1 has a mount_ext2fs command in the base system, so EXT2 filesystems should be supported to at least a basic degree.

Improve this answer
1

Quick test using tar. I believe the key that you may not be aware of the is the -p flag or option. This is (basically) try to preserve file permissions (and more).

On a FreeBSD system (but could be OpenBSD or even OSX):

mkdir t1-dir
touch t1-dir/t1-test
touch t1-dir/t1-read-only
chmod 600 t1-dir/t1-read-only
tar czf t1.tgz t1-dir
ls -l t1-dir
total 0
-rw-------   1 tigger  tigger     0  5 Sep 16:24 t1-read-only
-rw-r--r--   1 tigger  tigger     0  5 Sep 16:24 t1-test

On a Linux system (minutes later):

sftp <freebsd system>
get t1.tgz
exit
tar xzpf t1.tgz
ls -l t1-dir
total 0
-rw------- 1 tigger tigger 0 Sep  5 16:24 t1-read-only
-rw-r--r-- 1 tigger tigger 0 Sep  5 16:24 t1-test

If these two systems are on the same LAN you can set-up NFS or Samba share on either. Personally, I have a dedicated file and media server (FreeBSD) with a NFS set-up for shared files between FreeBSD and Linux and Samba set-up for Windows 10 and OSX.

Improve this answer
0

OpenBSD supports ext2 and ext3 with read/write and keeping permissions. OpenBSD doest not supports ext4.

To mount a linux filesystem (sd0a for example) onto an openbsd machine, do as root :

mkdir /mnt/linux
mount_ext2fs /dev/sd0a /mnt/linux

Use mount_ext2fs for mounting ext3 filesystems too.

Then you could copy files between directories using cp or tar like this for example:

(cd /mnt/linux && tar cf - .) | (cd /home/pkdick/linux && tar xpf -)

If you want to permanently share a linux directory with openbsd, use NFS (OpenBSD supports only NFS version 1 to 3).

On the linux side, declare exports and starts nfs daemons. On the OpenBSD side, do (in the following lines, replace linuxhostname by your linux box hostname or IP):

mkdir /mnt/linux

# to check that NFS services are available on your linux box:
rpcinfo -p linuxhostname

# to see the NFS exports available on your linux box:
showmount -e linuxhostname

# Then, for example, if you have an export /home/pkdick on your linux box:
mount linuxhostname:/home/pkdick /mnt/linux

You could declare this mount into your /etc/fstab:

linuxhostname:/home/pkdick /mnt/linux nfs rw,nodev 0 0
Improve this answer
1
  • 1
    OpenBSD supports ext2. It can also mount ext3 filesystems without immediately damaging them provided that said filesystems aren't using some uncommon options, but doing so will invalidate the journal. Neither ext2 nor ext3 is actually usable on OpenBSD: the code has known bugs, and it has been essentially abandoned many years ago. As for NFS, you can get excellent performance in either direction, but only after careful tuning on both ends. Without tuning it's pretty much guaranteed to suck. shrug
    – Satō Katsura
    Commented Sep 5, 2017 at 16:46
0

OpenBSD does offer read-only support for ext4 filesystems: this is useful if you are able to directly attach the Linux disk to the OpenBSD box.

As in most cases with BSD, the relevant man pages are excellent. Here are a few for starters: ext4(5) mount_ext2fs(8)

The OpenBSD Disk Setup FAQ (https://www.openbsd.org/faq/faq14.html) is also useful.

Your partitions will probably be found at /dev/sdX[d-p] (for SCSI driver disks) or /dev/wdX[d-p] (for discs using the WD100x compatible driver).

sysctl hw.disknames will give you a list of disks on your system.

To discover what partitions are available to a disk: disklabel sdX (replace sdX with your disk

To mount an ext4 drive read-only:

# mount -r /dev/sdX[d-p] /mountpoint

replace sdX[d-p] with the partition you have identified and /mountpoint with the location you would like it to be mounted. You will need admin access for this step.

Once you have mounted it read only, you should be able to copy files over to your new disk, avoiding any network bottlenecks you would have using NFS to complete the task.

Improve this answer
0

Ext2 is about the only common filesystem format between Linux and the BSDs that will natively preserve permissions. If user or group IDs differ, you may need to use chown or chgrp. EXT2 timestamps have very coarse resolution, EXT4 has nanosecond resolution. EXT variants, including EXT4, have been known to trash data (YMMV), so caveat emptor.

BSD mtree(8) is available on some Linux distributions (e.g. OpenSUSE), and can be used to save and restore permissions, timestamps, flags, owner/group etc. (i.e. using mtree files to hold the metadata can be used even with filesystems that are incapable of storing that data directly, including FAT variants). For that matter, bsdtar is also available on some Linux distributions, so you may be able to use compatible versions on both sides.

If you have two running systems (as opposed to a single multiboot system), rsync over a network connection can also preserve such metadata. If you haven't used rsync, there's a steep learning curve, but it's quite flexible once you get the hang of it.

I've used EXT variants to hold shared data on multiboot systems, and rsync over the network to share and synchronize data between machines. There are even drivers for MS systems to read and write EXT2. The biggest oddball that I know of among systems (I know little about macos, and I'd like to keep it that way) is illumos and the distributions based on it, which shares no common ground with all of the others (it uses ZFS natively, might support UFS, maybe NTFS, but not EXT; there's no UFS for MS machines, and limited availability of ZFS for some windows variants. [and unless you have enterprise-level disk capacity and support staff to stay on top of beadm etc., you probably don't want ZFS]; illumos also lacks USB 3 support, so unless you limit yourself to USB 2 or lower ports and devices, USB transfers aren't an option).

Improve this answer
3
  • rysnc isn't so bad. Start with rsync -av /source/ ip_address:/destination/ (trailing slashes are important) and use that until you need something more. Chances are you won't need something more until you're much more technical, at which point man rsync contains tons of examples (maybe too many, even - it's a very detailed document).
    – aggregate1166877
    Commented Aug 21, 2020 at 3:07
  • Your example is for network connections (not e.g. to another drive/partition on a multi-boot machine) and requires that ssh/rsh be set up and working (with the same user id at both ends), in addition to having rsync installed on both machines. rsync -a doesn't do some things; I typically use -asuEHPv, sometimes adding "long" (a.k.a. minus minus) options. The biggest problem is indeed the man page; options buried near the end, using jargon (e.g. "module"; remember "lunar excursion module"? ("module" was archaic in the 1980s) :-/) w/o definition (one has to also read the rsyncd.conf man page).
    – Bruce Lilly
    Commented Aug 24, 2020 at 15:35
  • Rsync can be used for local copying too if the both disks are in one machine: rsync -av /source/ /destination/. I just gave a net example because why not. The reason I stick to -av is because it's simple and predictable, and I prefer overwriting any changes (as apposed to -u that skips newer on receiver). I also avoid -H because it can easily consume GBs of RAM if the amount of files is long enough, because it needs to cross-ref all of them to check hard links. This is especially problematic with automated backups at 2:00AM. Also I rather like the manual. To each his own I guess :)
    – aggregate1166877
    Commented Aug 25, 2020 at 0:21

You must log in to answer this question.

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