SAP Basis
SAP AL11 File System Directories: How to View, Check, and Troubleshoot Application Server Files
Learn how to use SAP transaction AL11 to browse application server directories, check whether files exist, understand logical file paths, and troubleshoot permissions and file-location issues.
SAP transaction AL11 provides an SAP GUI view of directories and files on the application server. Basis teams use it to inspect interfaces, application logs, outbound files, inbound files, spool-related files, and other filesystem content that an SAP application reads or writes.
AL11 is an operational inspection tool rather than a general-purpose Linux file manager. It shows directories that are configured for the SAP system and exposes file metadata or content according to the user’s authorizations and the capabilities of the connected application server.
What AL11 is used for
AL11 helps an administrator answer practical questions such as:
- Does an expected interface file exist on the application server?
- Which application server host contains the file?
- When was the file last changed?
- Is the file empty, incomplete, or populated with the expected content?
- Which directory is configured for a particular interface or batch process?
The transaction is especially useful when an ABAP program writes to a shared directory and a downstream process reports that the file is missing. It provides a quick application-level view before an administrator investigates the operating system, mounted filesystems, permissions, or interface scheduling.
The SAP Basis system administration guide provides broader operational context for application-server administration, monitoring, and routine checks.
How to open an AL11 directory
- Start SAP GUI and log on to the relevant SAP system.
- Enter transaction
AL11in the command field. - Select a directory from the directory list.
- Review the files displayed for that directory.
- Select a file to inspect its attributes or display its contents, where the available function is permitted.
The directory list is system-specific. It commonly includes SAP working directories, interface directories, transport-related locations, temporary directories, and paths defined for customer developments. The visible entries depend on the system configuration and the application server to which the session is connected.
A directory entry can point to a physical path on the application server or to a logical file location maintained for the SAP system. Record the displayed path and host when reporting an issue because the same directory name can resolve differently across application servers.
Reading the directory list
Use the directory name, physical path, and application server information together. A file visible on one host may be absent on another host when a directory is local rather than shared. This distinction is important in a distributed SAP landscape with multiple application servers.
If the expected directory is missing, review the configured directory definitions and the application’s file-path settings. For interfaces that use logical file names, check the logical file path configuration in transaction FILE and compare it with the path used by the application.
How to check whether a file exists
To check for a file in AL11, open the directory that the application is expected to use and scan the listed file names. Confirm the complete name, extension, size, modification timestamp, and host. A file with the correct name but a zero length or an old timestamp may indicate that the producing job did not finish successfully.
For a reliable check, compare the AL11 result with the application configuration and processing log. Confirm the following:
- The producing job ran at the expected time.
- The file name matches the configured naming pattern.
- The file was written to the expected application server or shared path.
- The file size and timestamp indicate a completed write.
- The consuming process has access to the same location.
The SAP background job monitoring guide is useful when the file is generated by a scheduled ABAP job. Check the job log, spool, status, and runtime around the timestamp shown in AL11.
AL11 confirms what the SAP application server can expose through the transaction. It does not by itself prove that an external operating-system process can read the file, that a network share is mounted on every host, or that a downstream system has received the file.
How logical file paths fit into AL11
A logical file path separates an application’s configured file location from a hard-coded physical path. The application can refer to a logical name while the system configuration maps that name to a directory on the relevant application server.
When troubleshooting a logical file path:
- Identify the logical file name or logical path used by the application.
- Review its configuration in transaction
FILE. - Determine the physical directory and application-server context.
- Open the corresponding directory in AL11.
- Compare the configured path with the file name and timestamp produced by the application.
This process is useful after a system copy, application-server change, interface redesign, or filesystem reorganisation. It also helps distinguish a path-configuration problem from a failed batch job or an operating-system permission problem.
Troubleshooting missing files in AL11
Start with the expected producer and consumer. Identify the ABAP report, background job, interface framework, or external process that should create the file. Then establish the expected directory, file name, application server, and creation time.
If AL11 shows no file, inspect the following sequence:
- Application execution: Check whether the producing program or job completed successfully.
- Path resolution: Verify the logical file path or configured physical directory.
- Host selection: Confirm that the check is being made on the application server that performed the write.
- Filesystem availability: Check whether the directory, mount, or shared location was available at runtime.
- Authorization: Confirm that the SAP operating-system account and the external process have the required access.
- File naming: Check case, extension, date formatting, and any dynamically generated suffix.
- Post-processing: Determine whether another process moved, renamed, archived, or deleted the file.
Linux paths are case sensitive, so compare the path and file name exactly as configured. A successful job status does not always mean that the file reached the intended consumer; the application log and the downstream process log remain important evidence.
The SAP system log guide helps correlate filesystem and interface symptoms with system-level events recorded around the same time.
Permissions and safe operational practice
AL11 access is controlled by SAP authorizations and by the operating-system permissions applied to the SAP application-server account. A user may be able to display a directory while being unable to perform an operating-system action outside SAP. Conversely, an operating-system administrator may see a path that is not exposed in AL11.
Use the least intrusive action needed for the investigation. Prefer reading metadata and content over changing or deleting files. Preserve the original file when it may be needed for audit, replay, or root-cause analysis, and follow the organisation’s controls for sensitive business data.
Avoid treating AL11 as the normal interface for moving production files. File transfers, archiving, cleanup, and reprocessing should follow the application’s approved process or an authorised operating-system procedure. Document the host, directory, file name, timestamp, and action taken.
AL11 and related monitoring
AL11 answers the filesystem question: what is visible in the configured application-server directory? Other SAP tools answer adjacent questions. Background job monitoring shows whether a scheduled producer ran, while the system log can reveal related runtime or infrastructure events.
For a wider reference list of SAP transaction codes, see the SAP transaction code list. Use it to connect AL11 checks with job monitoring, system-log review, transport operations, and other Basis activities.
A concise incident record should include the transaction used, application server host, directory path, file name, file size, timestamp, producing job or program, consumer, and the next diagnostic step. This makes handoffs between functional, Basis, application, and infrastructure teams more efficient.