Receive directly onto qualified NAS storage

HTTP uploads and native QUIC pushes write verified ranges directly onto the receiving filesystem. Each completed file publishes without overwriting an existing destination. Receiving uses one payload allocation, with no separate staging volume or final payload copy. VOTPort creates its private .vot-stage directory on the destination filesystem itself.

Prepare the mount

Mount the share on the Linux server and expose it at VOTPORT_RECEIVE_DIR, including inside the container. Keep VOTPORT_DATA_DIR on local storage for SQLite, signing keys, and checkpoints. Qualifying receiving storage does not change the separate outbound library's filesystem requirements or its Fast receipts for existing files.

The supported NAS contract requires:

• NFSv4 with a hard mount and server-coordinated locks, or SMB3/CIFS with server inode identity and server ACL or POSIX support.
• Stable acknowledgments for both file data and namespace changes. SMB FLUSH or NFS COMMIT must satisfy the storage server's stable-storage contract.
• A private receiving namespace protected by server permissions from creation, with ancestors protected against replacement. Other programs using VOTPort's service identity must not modify its private files.
• Hard links, stable inode identity, namespace synchronization, and coordinated file locks.

Client-side UID, GID, or displayed mode bits do not prove server ACL protection. Unsupported options such as nostrictsync, nobrl, NFS soft mounts, or client-local flock emulation are refused. Linux nfs.recover_lost_locks must be disabled so lock loss is reported rather than silently reacquired; do not change that kernel setting while receiving.

A local receive root must be owned by the service account and protect its private control directory from replacement. Remove group/other write access, or use a sticky directory where others need to create files. VOTPort creates a missing local root with mode 0700 and does not change the permissions of an existing directory.

Check and enable receiving

1. Sign in as a platform administrator and open Storage > Receiving storage.
2. Review the mounted path, filesystem, source, readiness, and any failed checks.
3. For an unqualified NAS, confirm the storage server's stable-write behavior and private-namespace permissions with its administrator, then select both confirmations.
4. Select Check and enable receiving. Resolve any failed checks before accepting uploads.
5. Send a small test upload and inspect its file, receipt, and intended destination.

Qualification binds the share, mount root, receiving directory identity, and service UID. A missing or replaced mount stops receiving instead of writing into a local directory underneath it. The administration interface stays available when initial NAS qualification is missing.

The probe creates and flushes a small private file, checks an exclusive hard link and inode identity, synchronizes directories, and removes its own probe files. It does not simulate appliance power loss. Administrator confirmation supplies the storage-server contract that a filesystem probe cannot establish.

Understand the receipt

Qualified NAS receives use Balanced with provider POSIX_NAS (0x0005). The receipt records verified content and server-acknowledged durability. It does not claim independent physical-media readback or power-loss certification for a particular appliance.

Strict NAS receipts and macOS/Windows NAS receiving are not qualified by this Linux server implementation. Desktop senders on those systems can still upload to a qualified Linux VOTPort through HTTP or QUIC. Read the actual receipt profile; older receipts and outbound-library receipts have their own recorded assurance.

Recover without copying the package again

The final filename is an exclusive hard link to the verified staging inode; removing the private name leaves the same payload allocation. Files publish individually, so a failed package can contain completed files alongside retained partials.

Publication journals remain until the database checkpoint commits. If publication succeeds before a checkpoint fails, retry reconciles the existing published inode instead of deleting the completed file. A restart or uncertain file identity triggers verification before reuse; corrupt retained bytes must be sent again. Ordinary native receiving passes its verification witness directly into the receiver without an unconditional second hash or payload copy.

Reception workflows pin and verify those original files through retirement. No additional reception snapshot is required for checks or destination exports. Retained partial admissions remain charged against tenant quotas after their connections expire; resuming the same admission reuses its reservation.

Protect writer ownership

/received/.vot-stage/writer.lock is a permanent inode with an exclusive kernel lock. Heartbeat timestamps are diagnostic and never authorize takeover. Renewal writes and synchronizes through the retained lock handle to detect lost ownership; an I/O failure stops receiving. Startup and administrator-triggered recovery also enforce ownership.

Never remove the lock file to force takeover. Stop or fence the old writer and let the filesystem release or recover its lock before another host takes over. A hard-NFS syscall can remain blocked in the kernel after ownership loss, so elapsed time alone cannot establish that the old host is safe. See active-passive operation.

Failed recovery retains journals, partial files, and quota reservations; completed files are preserved. Automatic cleanup requires protection against other users replacing destination entries or ancestors. Where those permissions cannot be established, VOTPort refuses cleanup and the storage administrator manages deletion.

Send large sequences efficiently

Current browser and desktop HTTP senders submit windows of up to eight files when every file in the window fits in one upload chunk. The server can publish independent files in parallel within its bounded batch. Larger-file windows retain their existing path. Update both server and clients to obtain the complete small-file improvement.

On Linux CIFS, tcpnodelay can help when metadata latency dominates a sequence transfer. Measure your own workload before changing a deployed mount; do not weaken flush, lock, or permission settings to chase throughput. Network latency, storage behavior, and source preparation still determine the result.

Account for source preparation

Before native uploads begin, the client reads and hashes the selected files. Large-file preparation overlaps sequential reads with up to eight hashing workers, using a bounded buffer pool without another payload copy. Server library preparation and missing proof catalogs use the same helper. This changes preparation before transport; receiving verification, signed receipts, and NAS qualification requirements stay the same.

Update both the server and installed clients to use the current preparation path. When measuring a workload, record preparation separately from network transfer and final publication. Source-disk performance can dominate the time before sending begins.